Under consideration for publication in Theory and Practice of Logic Programming 



1 



> 

00 



o 

(N 



X: 



GEM: a Distributed Goal Evaluation Algorithm for 

Trust Management 

^ ; DANIEL TRIVELLATO*, NICOLA ZANNONE*, SANDRO ETALLE*' 

■ * Eindhoven University of Technology, Eindhoven, The Netherlands 
^ _ + University of Twente, Enschede, The Netherlands 
^ , {e-mail: {d. trivellato, n . zannone, s . etalle}@tue . nl) 

■ submitted 30 May 2011; revised 13 March 2012; 1 7 July 2012; accepted 24 September 2012 

Note: To appear in Theory and Practice of Logic Programming (TPLP). 

O: 

1-^ ■ Abstract 

^ _ Trust management is an approacii to access control in distributed systems wiiere access decisions are 

based on policy statements issued by multiple principals and stored in a distributed manner In trust 
management, the policy statements of a principal can refer to other principals' statements; thus, the 
process of evaluating an access request (i.e., a goal) consists of finding a "chain" of policy statements 
that allows the access to the requested resource. Most existing goal evaluation algorithms for trust 
management either rely on a centralized evaluation strategy, which consists of collecting all the rele- 
, vant policy statements in a single location (and therefore they do not guarantee the confidentiality of 

■ intensional policies), or do not detect the termination of the computation (i.e., when all the answers of 
a goal are computed). In this paper we present GEM, a distributed goal evaluation algorithm for trust 
management systems that relies on function-free logic programming for the specification of policy 
statements. GEM detects termination in a completely distributed way without disclosing intensional 
policies, thereby preserving their confidentiality. We demonstrate that the algorithm terminates and 
is sound and complete with respect to the standard semantics for logic programs. 
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1 Introduction 

The widespread availability of the Internet has led to a significant increase in the number 
of collaborations, services and transactions carried out over networks spanning multiple 
administrative domains (e.g., web services). Such collaborations are frequently character- 
ized by the interaction of users and institutions (hereafter indistinctly referred to as princi- 
pals) who do not know each other beforehand. For this reason, in such distributed settings, 
attribute-based approaches to access control are mostly preferred to identity-based solu- 
tions (lEllison et al. 1999] l. Consider, for instance, an international medical research project 
Alpha involving several companies worldwide. Project A Zp/ia is funded and coordinated by 
the multinational pharmaceutical company mc which, among its tasks, appoints the part- 
ners of the project consortium. In this scenario, it is likely that company mc does not know 
the project members of each partner company personally, i.e., does not know their iden- 
tity. Therefore, rather than on the identity of the project members, the policies regulating 
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the access to project's documents will be based on their attributes (e.g., project member- 
ship, specialization) and their relationships with other principals (e.g., partner companies, 
departments within a company). 

Trust management is an approach to access control in distributed systems where access 
decisions are based on the attributes of principals, which are attested by digitally signed 
certificates called digital credentials jBlaze et al. 19961 1. Digital credentials (or simply cre- 
dentials) are the digital counterpart of paper credentials. Credentials are defined and de- 
rived by means of policy statements that specify the conditions upon which a credential is 
issued, where conditions are in turn represented by credentials. A distinguishing ingredient 
of trust management is that all the principals in a distributed system are free to define such 
policy statements and determine where to store them. The set of policy statements defined 
by a principal forms the policy of that principal. In the scenario above, for instance, the 
rules of company mc dictating the conditions for the membership of a user to project Al- 
pha (e.g., a Master degree in chemistry) form the policy of mc. These statements can be 
stored by mc or at another principal's location (e.g., by each partner company). 

In trust management languages, policy statements are often expressed as Horn clauses 
(ILi and Mitchell 2003b where each atom represents a credential, and is possibly annotated 
with the storage location of the statements defining the credential. Depending on the lan- 
guage, the location can be expressed implicitly JCzenko and Etalle 20071 ILi et al. 2003] l or 
explicitly jAlves et al. 20061 IBecker 2005b . While typically principals do not have direct 
access to each other policies, the statements of a principal can refer to other principals' 
policies, thereby delegating authority to them. For instance, assume that a hospital h au- 
thorizes the members of project Alpha certified by the local pharmaceutical company cl 
to access the (anonymized) medical records of its patients suffering from genetic diseases. 
The policies governing this scenario can be represented by the following clauses: 

1. mayAccessMedRec(/i,X) ^ memberOfAlpha(cl,X). 

2. memberOfAlpha(cl,X) projectPartner(mc,y), memberOfAlpha(y,X). 

3. projectPartner(mc,c2). 

4. projectPartner(mc,c3). 

5. projectPartner(mc,c4). 

6. memberOfAlpha(c2,X) memberOfAlpha(cl,X). 

7. memberOfAlpha(c2,aHce). 

8. memberOfAlpha(c3,6o6). 

9. memberOfAlpha(c4,c/iarHe). 

where the first parameter of each atom denotes the location where the credential that the 
atom represents is defined. Here, hospital h relies on the policy statements of cl to deter- 
mine who is authorized to access the hospital's medical records (clause 1); in turn, cl relies 
on the policy statements of mc and the partner companies appointed by mc for the defini- 
tion of project A//9/!fl's members (clause 2). Therefore, the process of evaluating a request 
to access the hospital's records (i.e., a goal) consists of deriving a "chain" of policy state- 
ments delegating the authority from hospital h (i.e., the resource owner) to the members of 
project (i.e., the authorized principals). This process, referred to as credential chain 

discovery (ILi et al. 2003b . can be addressed using goal evaluation algorithms. 

Since in trust management pohcies are stored at different locations, goal evaluation al- 
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gorithms require principals to disclose their policy statements to other principals to enable 
credential chain discovery. In particular, for a successful computation, principals need to 
disclose at least (part of) their extensional policy, that is, the credentials that can be de- 
rived from their policy and are required for an access decision. For example, suppose 
that hospital h wants to determine who can access the medical records of its patients. 
To compute the answers of this goal, it is clear that cl has to disclose to h the creden- 
tials certifying all the project members. Most of the existing goal evaluation algorithms 
(e.g., jCzenko and Etalle 20071 ILi et al. 2d03] l). however, rely on a centralized evaluation 
strategy and require principals to disclose also (part of) their intensional policy, i.e., the 
policy statement used to derive those credentials (e.g., clause 2 in the example policy). 

We argue that one of the advanced desiderata of goal evaluation algorithms for trust 
management is that the amount of information about intensional policies that principals 
reveal to each other should be minimized. In fact, intensional policies might contain sen- 
sitive information about the relationships among principals, whose disclosure would leak 
valuable business information that can be exploited by other principals in the domain (e.g., 
rival companies) JYu and Winslett 20031) . For example, if el's policy was disclosed to other 
principals for evaluation (e.g., to hospital h), the involvement of mc in project A/p/za along 
with the list of all project partners would be exposed. As a consequence, some competitors 
of mc could start investing on similar projects, or could try to get at the project members to 
acquire sensitive information and project results. Furthermore, the loss of confidentiality of 
intensional policies can result in attempts by other principals to influence the policy evalua- 
tion process ( IStine et al. 20081 1. and allows adversaries to know what credentials they need 
to forge to illegitimately get access to a resource ( IFrikken et al. 2006] l. 

To protect the confidentiality of intensional poUcies, it is necessary to design a com- 
pletely distributed goal evaluation algorithm that discloses as few information on inten- 
sional policies as possible. Since bottom-up approaches to goal evaluation (e.g., fixpoint se- 
mantics JPark 19691 ), magic templates JRamakrishnan 199T1 ) and magic sets dChen 1997] l) 
require knowledge of all the policy statements that depend on a given credential, they do 
not represent an applicable solution to our problem. Hence, a top-down approach to goal 
evaluation needs to be employed. The design of a distributed top-down algorithm, however, 
requires addressing two main problems: (a) loop detection, and (b) termination detection. 
In addition, to reduce network overhead, the goal evaluation algorithm should attempt to 
decrease the number of messages that principals exchange. 

Loops are formed when the evaluation of a goal leads to a new request for the same goal. 
In our scenario, for example, to determine the set of project members without disclosing 
its intensional policy to hospital h, cl should first request the list of project partners to 
mc, and then the list of their project members to c2, c3 and c4. Since c2 in turn relies 
on the policy statements of cl to determine its project members, c2 would pose the same 
request back to cl, forming a loop. Fig. [T] shows the "call graph" originating from this 
sequence of requests. Intuitively, cl should detect the loop and refrain from evaluating 
c2's request, as doing so could lead to a non-terminating chain of requests. Even though 
in the example scenario loops could be avoided, for instance, by requiring a single com- 
pany (e.g., mc) to define the set of project members, this cannot be guaranteed in distributed 
systems characterized by the absence of a coordinating principal. Examples of such scenar- 
ios include self-organizing networks (Di Marzo Serugendo et al. 2004 1 and access control 
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member O f Alpha(c2, X) memberO f Alpha{c3, X) member O f Alpha(ci, X) 



Fig. 1. Call Graph of the Evaluation of the Example PoUcies 



policies based on independent information sources (e.g,. the Friend of a Friend - FOAF - 
project dFOA}). 

Existing goal evaluation algorithms employ tabling techniques ( |Bry 1989{IChen and Warren 19961 
ITamaki and Sato 1986MVieille 1987l l for the detection of loops. Although some of these al- 
gorithms resort to a distributed tabling strategy (e.g., ( IDamasio 20001 iHu 1997l l). they rely 
on centralized data structures to detect termination - i.e., to detect when all the answers 
have been collected - thus leaking some policy information. In fact, the real challenge in 
designing a goal evaluation algorithm that does not disclose intensional policies lies in de- 
tecting termination distributedly. In the example, we have the following possible answer 
flow: c3 returns bob as answer to cl, which forwards it to h and c2; c4 returns charlie as 
answer to cl; cl sends charlie as additional answer to h and c2; c2 returns alice, bob, and 
charlie as answer to cl, which sends alice as additional answer to h and c2. At this point, 
all the requests have been fully evaluated, but cl does not know whether c2 will ever send 
additional answers. In other words, cl is waiting for c2 to announce that its evaluation 
has terminated, and in turn c2 is waiting for cl to announce that its evaluation has termi- 
nated. This situation is not acceptable in the context of access control, where a decision 
(positive or negative) always needs to be made. A few top-down goal evaluation algo- 
rithms are able to detect the termination of a computation distributedly (lAlves et al. 20061 



Zhang and Winslett 2008 1; however, they do not detect when the single goals within a com- 
putation are fully evaluated. In top-down goal evaluation, detecting when the evaluation of 
a goal has terminated is necessary to allow (a) for memory deallocation and (b) the use of 
negation, which is employed by some systems to express non-monotonic constraints (e.g., 
separation of duty) jCzenko et al. 20061 Dong and Dulay 2010 1. 



Finally, another non-trivial issue in designing a distributed goal evaluation algorithm is 
determining when a principal should send the answers to a request. The simplest solution 
is to force each principal to send an answer as soon as the principal has computed it, as 
done, for example, in ( lAlves et al. 20061 1. This is, however, suboptimal from the viewpoint 
of network overhead; in the example above, cl eventually sends three distinct messages to 
h and c2, one for each answer A more network-efficient solution would be for cl to wait 
for the answers from c3 and c4 before sending its answers to the other principals. A naive 
"wait" mechanism, on the other hand, might cause deadlocks. For instance, if cl also waits 
for c2's answers, the computation deadlocks. In a trust management system, where net- 
work latency is likely to be a bigger bottleneck than computational power, it is preferable 
to have a mechanism that allows principals to wait until they collect the maximum possi- 
ble set of answers before sending them to the requester, while avoiding deadlocks. Even 
though this solution may delay the identification of the answers of ground goals (i.e., goals 
expecting a single answer), the "superfluous" computed answers might become relevant 
for the evaluation of other goals, reducing the delay in future computations. 
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In this paper we present GEM, a goal evaluation algorithm for trust management sys- 
tems that addresses all the above mentioned problems. In GEM, policy statements are ex- 
pressed as function-free logic programming clauses; each statement is stored by the prin- 
cipal defining it. GEM computes the answers of a goal in a completely distributed way 
without disclosing intensional policies of principals, thereby preserving their confidential- 
ity. The algorithm deals with loops in three steps: (1) detection, (2) processing, and (3) 
termination. To enable loop detection, we employ a distributed tabling strategy and asso- 
ciate an identifier to each request for the evaluation of a goal. After its detection, a loop 
is processed by iteratively evaluating the goals in the loop until a fixpoint is reached, i.e., 
no more answers of the goals in the loop are computed, at which point their evaluation is 
terminated. This three-steps approach enables GEM to detect both when the whole compu- 
tation has terminated, and when the single goals within a computation are fully evaluated, 
allowing for the use of non-mono tonic constraints in policies. In addition, by exploiting 
the information stored in the table of a goal, principals are able to delay the response to a 
request until a "maximal" set of answers of the goal has been computed without running 
the risk of deadlocks. We demonstrate that GEM terminates and is sound and complete 
with respect to the standard semantics for logic programs. 

The remainder of the paper is structured as follows. Section |2]presents preliminaries on 
logic programming and SLD resolution. Section|3]introduces GEM and its implementation. 
Section|4]demonstrates the soundness, completeness and termination of the algorithm, and 
discusses what information is disclosed by GEM during the evaluation of a goal. Section|5] 
presents the results of experiments conducted to evaluate the performance of GEM. A pos- 
sible extension of GEM to deal with negation is presented in Section|6] Section|2]discusses 
related work. Finally, Section[8]concludes and gives directions for future work. 



2 Preliminaries on Logic Programming 



In this section we revisit the concepts of logic programming (Apt 1990 1 that are relevant 
to this paper. In particular, we review function-free logic programs. 

An atom is an object of the form . . . , i„) where p is an n-ary predicate symbol 
and ti, . . . ,tn are terms (i.e., variables or constants). An atom is ground if ti, . . . , i„ are 
constants. A clause is an expression of the form H <— Bi, . . . , _B„ (with n > 0), where 
H is an atom called head and Bi, . . . , _B„ (called body) are atoms. If n = 0, the clause 
is a fact. A program is a finite set of clauses. We say that an atom A is defined in the 
program P if and only if there is a clause in P that has an atom A' in its head such that 
A and A' are unifiable. Finally, a goal is a clause with no head atom, i.e., a clause of the 
form ■(— Bi, . . . , Bn- Without loss of generality, in this paper we restrict to goals with 
< n < 1, that is, consisting of at most one atom. The empty goal is denoted by 0. 

SLD resolution (Selective Linear Definite clause resolution) jKowalski I ) is the standard 
operational semantics for logic programs. In this paper, we refer to SLD resolution with 
leftmost selection rule (extending the algorithm to an arbitrary selection rule is trivial). 
Computations are constructed as sequences of "basic" steps. Consider a goal Gq = 
Bi, . . . , Bn and a clause c in a program P. Let H ^ B[, . . . , B'^ be a variant of c variable 
disjoint from Si, ... , _B„. Let Bi and H unify with most general unifier (mgu) 9. 
The goal G\ — ^ {B[, . . . , B'^, B^, ■ ■ ■ , Bn)9 is called a resolvent of Gq and c with 
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selected atom Bi and mgu 9. An SLD derivation step is denoted by Go — > Gi. Clause 
H ^ B[, . . . , B'^ is called input clause, and atom Bi is called the selected atom of Go- 
An SLD derivation is obtained by iterating derivation steps. The sequence (5 := Go — ^ 

Gi % ■ ■ ■ ^ Gn • • ■ is called a derivation of PU {Go}, where at every step the input 
clause employed is variable disjoint from the initial goal Gq and from the substitutions and 
the input clauses used at earlier steps. Given a program P and a goal Go, SLD resolution 
builds a search tree for P U {Go}, called (derivation) tree of Go, whose branches are SLD 
derivations of P U {Go}. Any selected atom in the SLD resolution of P U {Go} is called 
a subgoal. SLD derivations can be finite or infinite. If 5 := Go — V • ■ • ^ G„ is a finite 
prefix of a derivation, we say that 9 = (?i • • • 0„ is a partial derivation and 6* is a partial 
computed answer substitution of P U {Go}. If S ends with the empty goal 0, 9 is called 
computed answer substitution (c.a.s.). Let Go = <— Pi. Then, we also call 9 a solution of 
Go and Bi9 an answer of Go. The length of a (partial) derivation 6, denoted by len{S), is 
the number of derivation steps in 6. 



The most commonly employed technique to prevent infinite derivations is tabling ( Bry 1 989 



IChen and Warren 1996l|Guo and Gupta 200T]IShen et al. 2001irfamaki and Sato 1986IIVieille 19871 



IZhou and Sato 2003] l. Given a goal Go consisting of an atom defined in a program P, 
tabling-based goal evaluation algorithms create a table for each (sub)goal in the SLD res- 
olution of P U {Go}, to keep track of the previously evaluated goals and thus avoid the 
reevaluation of a subgoal. Tabling algorithms differ mainly in the data structures employed 
for the evaluation of goal Go. Linear tabling (IShen et al. 20011 IZhou and Sato 2003T l and 



DRA (Guo and Gupta 2001 1, for instance, evaluate Go by building a single derivation tree 



of Go. In SLG resolution (IChen and Warren 19961 1, on the other hand, goal Go is evaluated 
by producing a forest of (partial) derivation trees, one for each subgoal in the resolution of 
PU {Go}. In SLG, the evaluation of Go starts by ordinary resolution with the clauses in P; 
as in SLD, a subgoal Gi is selected in a resolvent of Go. If a tree for a variant of Gi already 
exists, Gi is added to the set of consumers of the corresponding table. Otherwise, a tree 
for Gi is created. When a new answer of a subgoal is found, it is stored in the respective 
table and it is propagated to its consumer subgoals. The evaluation of a goal by means of a 
forest of derivation trees proposed by SLG resolution is at the basis of the distributed goal 
evaluation algorithm proposed in this paper 



3 The GEM Algorithm 

In this section we first introduce some definitions and basic assumptions underlying our 
work. Then, we present GEM and discuss its implementation. 



5.7 Definitions and Assumptions 

Similarly to other works on trust management (e.g., (ILi et al. 2003llArves et al. 2006l l). we 
consider policy statements expressed as function-free logic programming clauses. As in 
most trust management systems, policy statements are stored at different locations: each 
location is controlled by a principal who is responsible for defining and evaluating the pol- 
icy statements at that location. We assume a one-to-one correspondence between locations 



GEM: a Distributed Goal Evaluation Algorithm 



7 



and principals; accordingly, we use a principal's identifier to refer to the location she con- 
trols. To represent the location where a policy statement is stored, we require every atom to 
have the form p{loc, ii, . . . , <„), where loc is a mandatory term that represents the location 
where the atom is defined, and ti, . . . ,tn are terms. For instance, p{bob, . . .) refers to p as 
defined by Bob and thus stored at Bob's location. 

Let a be a principal in the trust management system. We call the set of policy statements 
defined by a the local trust management policy (or simply the policy) of principal a. The 
set of clauses with non-empty body in a's policy is the intensional policy of a, while the 
set of facts that can be derived from principal a's policy forms the extensional policy of a. 
The set of all the local policies in the trust management system is called global policy. 

Since we consider the confidentiality of intensional policies to be a main concern in trust 
management systems, we assume that principals do not have access to the policies at other 
principals' locations. As a consequence, the answers of a goal cannot be derived by build- 
ing the derivation tree of the goal as done by SLD resolution, as this might involve input 
clauses defined by different principals. Similarly to SLG resolution, in GEM a principal 
computes the answers of a goal defined in her policy by building the partial derivation 
tree of the goal. Differently from a derivation tree, in the partial derivation tree of a goal G 
only the first derivation step is obtained by resolution with the clauses defining G; all the 
subsequent steps are by substitution with the solutions of the subgoals of G. 

Definition 1 

Let G = ^ A be a goal and Pa be the policy in which A is defined. A partial derivation 
tree of G is a derivation tree with the following properties: 

• the root is the node {A -(^ A); 

Q 

• there is a derivation step (A <— ^) — > (A _Bi, . . . , -B„)0, where {A ^ A) is the 
root, iff there exists a clause H <— Bi, . . . , _B„ in Pa (renamed so that it is variable 
disjoint from A) s.t. A and H unify with 6 = mgu{A, H); 

• let (j4 <— Bi, . . . , Bn) be a non-root node, and Ans be a set of answers of goal 
^ Bi, for each answer B'l G Ans (renamed so that it is variable disjoint from 
Bi) there is a derivation step {A <— . . . , _B„) A {A <— i?2, ■ . • , Bn)9, where 
9 = mguiBi, B[); 

• for each branch {A ^ A) {A ^ Bi, . . . , B„)9a A ... A (A ^ 0)9q9i • • • 6I„, 
we say that A9 (with 9 = 9q9i ■ ■ ■ 9n) is an answer of G using clause H ^ 

Bi,...,Bn. □ 

Note that, to enable the evaluation of an atom Bi in the partial derivation tree of goal G, 
the location where Bi is defined must be known by the principal evaluating G. A straight- 
forward solution for guaranteeing that this requirement is satisfied would be to impose the 
location parameter of each atom in a policy to be ground at policy definition time. This, 
however, would limit the constraints that a principal can express. Consider, for instance, 
clause 2 on page 2. In the clause, the location parameter of atom memberOfAlpha(Y,X ) 
is determined at runtime based on the answers of projectPartner(mc,Y). Therefore, rather 
than relying on a "static" safety condition, we require the location parameter of an atom to 
be ground when the atom is selected fi^r evaluation. If this is not the case, the computation 
fiounders. A discussion on how to write flounder-free programs and queries is orthogonal 
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Fig. 2. Classification of Goal Evaluation Algorithms in Terms of Disclosed Policy Infor- 
mation 



to the scope of this paper. Here, we just mention that there exist well-established techniques 
based on modes (Apt and Marchiori 1994 1 which guarantee that certain parameters of an 
atom are ground when the atom is selected for evaluation. 

Finally, we define a classification criteria for goal evaluation algorithms based on dis- 
closed policy information. We will use such criteria to compare GEM with the existing 
algorithms (see Section |7]i. The classification criteria consists of two elements: an exten- 
sional and an intensional policy confidentiality level. Intuitively, the first characterizes al- 
gorithms in terms of how much information about extensional policies they disclose during 
goal evaluation, while the second refers to the disclosure of intensional policies. Confiden- 
tiality levels define an increasing scale used to characterized from the most conservative 
approaches where no policy information is disclosed, to the least confidentiaUty-preserving 
solutions which disclose respectively extensional and intensional policies in full. The ex- 
tensional and intensional confidentiality levels are presented in Fig.|2] In a goal evaluation 
algorithm classified as E1-I2, for example, principals disclose to a requester all the answers 
of the requested goals. In addition, all the dependencies among the goals in the global pol- 
icy are disclosed to the principals responsible for goal evaluation. 



3.2 Intuition 

In this section we describe how GEM computes the answers of a goal. Given a goal G, 
GEM computes the answers of G by evaluating one branch of its partial derivation tree at a 
time; this may involve the generation of evaluation requests for subgoals that are processed 
by different principals at different locations. When all the answers from each branch of the 
tree of G have been computed, they are sent to the principal(s) that requested the evaluation 
of G. G is completely evaluated when no more answers of G can be computed. 

To illustrate how GEM works in detail, we consider the scenario presented in Section[Tl 
where several pharmaceutical companies collaborate in the research project Alpha. How- 
ever, we slightly modify the global policy to better focus on the algorithm's features. In 
particular, we assume that company cl already knows which are the partner companies in 
project A//9/!fl, without needing to request them to mc, and we reduce the partner companies 
to c2 and c3 only. Furthermore, we consider a research institute ri that works on project 
Alpha in partnership with company c2. As a result, we have the following global policy: 

1. memberOfAlpha(cl,X) ^ memberOfAlpha(c2,X). 

2. memberOfAlpha(cl,X) ^ memberOfAlpha(c3,X). 

3. memberOfAlpha(c2,X) ^ memberOfAlpha(ri,X). 

4. memberOfAlpha(c2,aZice). 
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I 

memberOfAlpha{cl,X) 
\ 

memberOfAlpha(c2,X) memberOfAlpha{c3,X) 
\ 

memberOfAlpha{ri,X) 



Fig. 3. Call Graph of the Example Global Policy 



5. memberOfAlpha(c3,bo&). 

Recall that the first parameter of the atom in the head indicates the principal storing and 
evaluating a clause: clauses 1 and 2 are evaluated by cl, clauses 3 and 4 by c2, and clause 5 
by c3. Suppose that hospital h sends to company cl a request for (the evaluation of) goal 

memberOfAlpha(cl,X) (for a matter of readability, from here on we omit the <— symbol 
when referring to a goal -s— A, and we simply refer to it as A). Fig.[3]shows the call graph 
of the evaluation of memberOfAlpha(c\,X) with respect to the example global policy. A 
call graph is a directed graph where nodes represents goals and edges connect each goal to 
its subgoals (ILeuschel et al. 1998] l. In other words, edges represent (evaluation) requests. 

GEM performs a depth-first computation. When cl receives the initial goal, it evaluates 
the first applicable clause in its policy (i.e., clause 1) and sends a request for memberOf- 
Alpha(c2,X) to c2. In turn, c2 sends a request for memberOfAlpha( ri,X) to ri. ri does not 
have any clause applicable to membe rOfAlpha( ri,X) and returns an empty set of answers to 
c2. c2 evaluates the next appUcable clause (i.e., memberOfAlpha(c2,alice)), which is a fact. 
Since c2 does not have any other clause to evaluate, it sends the computed answer to cl. 
cl applies the next clause (clause 2) and sends a request for membe rOfAlpha(c3,X) to c3, 
that returns answer membe rOfAlpha(c3, bob) to cl after applying clause 5. At this point, 
membe rOfAlpha(cl,X) is completely evaluated and cl sends answers membe rOf Alp ha(cl, 
alice) and memberOfAlpha(c\,bob) to hospital h. 

The evaluation of a subgoal of a goal G, however, may lead to new requests for G, 
forming a loop. In our scenario, this reflects the "sharing" of project members among 
partner companies. Consider, for instance, the global policy above with the following two 
additional clauses, stored by c2 and ri respectively; 

6. memberOfAlpha(c2,X) ^ memberOfAlpha(cl,X). 

7. memberOfAlpha (ri,X) ^ memberOfAlpha(c2,X). 

The new call graph is shown in Fig. |4(a)| Now, when ri receives the request for member- 
OfAlpha(ri,X) from c2, it applies clause 7 and sends a request for memberOfAlpha(c2,X) 
back to c2, forming a loop. Similarly, the evaluation of clause 6 by c2 leads to another 
loop. The requests forming a loop are identified by boxed atoms in Fig. |4(a)| Formally, a 
loop is defined as follows. 

Definition 2 

Let G be the call graph of the evaluation of a goal G with respect to a global policy P. 
A loop is a maximal subgraph of G consisting of goals Gi , . . . , Gfc such that for each 
Gi G {Gi, . . . , Gfc} there exists a path that leads from Gi to Gi and from Gi to (a variant 
of) Gi . Then, we say that goals Gi , . . . , G^ are involved in the loop. □ 
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(b) Compact Call Graph with Request Identifiers and Loops 

Fig. 4. Call Graph of the Example Global Policy with Loops 



Intuitively, requests forming a loop should not be further evaluated. However, in the ex- 
ample above cl and c2 cannot detect whether a request forms a loop, as in a distributed sys- 
tem several independent requests for the same goal can occur In most of the existing goal 
evaluation algorithms (e.g., JChen and Warren 1996tlDamasio 20001 ILi et al. 20031) ). loop 
detection (and termination) is made possible by the system's "global view" on the deriva- 
tion process. For example, centralized goal evaluation algorithms such as SLG jChen and Warren 19961 ) 
and RT jLi et al. 20031) identify loops by observing goal dependencies respectively in the 
call stack and in the call graph of the global policy. In a similar way, the distributed algo- 
rithm proposed by Damasio jDamasio 20001 ) requires the dependency graph of the global 
policy to be known to all principals. Such global view, however, implies the loss of policy 
confidentiality. GEM detects loops and their termination in a completely distributed way 
without resorting to any centralized data structure. In GEM, loops are handled in three 
steps: (1) detection, (2) processing, and (3) termination. 



Loop Detection. Loops are detected by dynamically identifying Strongly Connected Com- 
ponents (SCCs). A sec is a set of mutually dependent subgoals. More precisely, a set of 
goals Gi, . . . ,Gk is part of a SCC if for each Gi E {Gi, . . . , Gk} there exists a goal 
Gj E {Gi, . . . , Gi-i, Gi+i, . . . , Gk} such that Gi and Gj are involved in a common 
loop. To enable the identification of SCCs, we assign to each request a unique identifier 
from an identifier dotnain. 

Definition 3 

An identifier domain is a triple (/, ^), where: 

• / is a set of sequences of characters called identifiers; 

• □ is a partial order on the identifiers in /. Given two identifiers idi, id2 G / s.t. 
idi C id2, we say that idi is lower than id2, and id2 is higher than idi; 
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• ^ is a partial order on the identifiers in /. Given two identifiers idi, id2 G / s.t. 
idi ^ id2, we say that id-z is side of idi. 

• The following property holds: Vidi, jc?2, id^, id4 G / if idi C id2, id^ C id4, and 
id2 ^ id4, then idi ^ i^a- D 



Intuitively, □ defines a top-down ordering and M> defines a left-to-right ordering with 
respect to the call graph of the global policy. In other words, C reflects the order in which 
the subgoals in a branch of the graph are evaluated, whereas ^ reflects the order in which 
the branches are inspected. Several identifier domains can be employed whose identifiers 
respect these partial orders (e.g., based on alphanumeric ordering). For the sake of sim- 
plicity, in the sequel we consider identifiers obtained as follows: given a request for a goal 
G with identifier ido, the identifier of the request for a subgoal Gi of G has the form 
idgSi, denoting the concatenation of ido with a sequence of characters si. Then, IZ is a 
prefix relation, and we have that idgsi □ ido- Ordering ^ is a partial order on the strings 
composing the identifiers. For example, consider another subgoal G2 of G with identifier 
idoS2, which is evaluated after Gi. Then, we have that idoSi ^ idoS2- Even though iden- 
tifiers from this domain leak some policy information (see Section 14.21 for more details), 
they allow for an easy visualization of the relationships among identifiers. When applying 
GEM in practice, more confidentiality-preserving identifier domains can be employed. 

A loop is detected when a principal receives a request with identifier id2 for a goal G 
such that a request idi for a variant of G has been previously received and id2 C idi. 
Accordingly, we call request id2 a lower request for G, while request idi is a higher 
request for G. We use the identifier of the higher request for G, idi, as the loop identifier. 
Goal G is called the coordinator of the loop. An SCC may contain several loops. Given two 
loops with identifiers idi and id2, we say that loop id2 is lower than loop idi if C idi. 
The coordinator of the highest loop of the SCC (i.e., the loop with the highest identifier) is 
called the leader of the SCC. 

Fig. |4(b)| represents a compact version of the call graph in Fig. |4(a)[ where loop coor- 
dinators are depicted only once. In addition, in Fig. |4(b)| edges are labeled with the cor- 
responding request identifier In the remainder of the paper, we concatenate the identifier 
of a request for a goal evaluated by company cl with meta-variables of the form cl^. 
Thus, for instance, cli and CI2 are two distinct sequences of characters generated by cl. 
In the figure, identifiers hi, hicli, /11CI2, and hiclic2i identify higher requests for goals 
memberOfAlpha(cl,X), memberOfAlpha(c2,X), memberOfAlpha(c3,X), and memberOfAl- 
pha(ri,X) respectively; identifiers hiclic2irii and hiclic22 identify lower requests for 
goals memberOfAlpha(c2,X) and memberOfAlpha(cl,X) respectively. Goals inherit the or- 
dering associated with the identifier of their higher request. Therefore, in Fig. |4(b)| goal 
memberOfAlpha(c\,X) is higher than memberOfAlpha(c2,X), memberOf-Alpha(c2>,X), and 
memberOfAlpha(ri,X). Goals memberOfAlpha(c2,X) and memberOfAl-pha(cl,X) are the 
coordinators of loops hicli and hi respectively. Loop hicli is lower than loop hi, which 
is the highest loop of the SCC; therefore, memberOfAlpha(cl,X) is the leader of the SCC. 
The identifier of the lower requests enables cl and c2 to determine the subgoals involved 
in the loop, which are memberOfAlpha(c2,X) and memberOfAlpha( ri,X) respectively. 
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Loop Processing. When a loop is detected, GEM sends the answers of the coordinator 
already computed to the requester of the lower request together with a notification about the 
loop. The loop is then processed iteratively as follows; in turn, each principal (a) processes 
the received answers, (b) "freezes" the evaluation of the subgoal involved in the loop and 
evaluates other branches of the partial derivation tree of the locally defined goal. Then, 
when all branches have been evaluated, (c) the new answers are sent to the requester of the 
higher request with a notification about the loop. We call the execution of actions (a), (b), 
and (c) a loop iteration step. 

Definition 4 

Let G be a goal, and Gi, . . . , Gfc be the subgoals of G s.t. G,Gi, . . . ,Gk are involved in 
a loop id. A loop iteration step for goal G is a three-phases process in which the principal 
evaluating G: 

(a) Receives a set of answers of the subgoals Gi , . . . , Gfc of G. 

(b) Evaluates all the nodes in the partial derivation tree of G whose selected atom is not 
involved in a loop. 

(c) Sends the newly derived answers of G to the requester of G. □ 

The definition above applies to all the goals involved in a loop but the loop coordinator 
The loop iteration step for a loop coordinator differs in the order in which the phases occur. 
In particular, for the coordinator phase (c) precedes (a) and (b), and the latter two are 
executed only after a loop iteration step for the other goals in the loop has been performed. 
In other words, the processing of the coordinator occurs only after all the other goals in 
the loop have been processed. This is because the coordinator, being the "highest goal" in 
the loop, is assigned the task of overseeing its processing. More precisely, it is in charge 
of starting (phase (c)) a new loop iteration whenever the answers of its subgoals lead to 
new answers of the coordinator (computed in phases (a) and (b)), i.e., until a fixpoint is 
reached. This difference is reflected in the definition below. 

Definition 5 

Let Gi, . . . , Gfc be the goals involved in a loop idi s.t. goal Gi is the loop coordinator. A 
loop iteration is a process where: 

1 . The answers of Gi that have not been previously sent are sent to the requesters of 
the lower requests for Gi (phase (c) of the loop iteration step for the coordinator). 

2. For each Gi g {G2, . . . , Gfc} a loop iteration step for G; is performed, s.t. for each 
Gj G {G2, . . . , Gfc}, if Gj is lower than Gi then the loop iteration step for Gj is 
executed before the loop iteration step for Gi. 

3. The principal evaluating Gi receives a set of answers of the subgoals of Gi involved 
in loop idi (phase (a) of the loop iteration step for Gi). All the nodes in the partial 
derivation tree of Gi whose selected atom is not involved in a loop are processed 
(phase (b) of the loop iteration step). □ 

If the processing of the received answers leads to new answers of the coordinator, these 
new answers are sent to the requesters of lower requests, starting a new iteration. Other- 
wise, a fixpoint has been reached (i.e., all possible answers of the goals in the loop have 
been computed) and the answers of the coordinator are sent to the requester of the higher 
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request. Notice that a goal in a higher loop may eventually provide new answers to a goal 
in a lower loop: the fixpoint for a loop must be recalculated every time new answers of its 
coordinator are computed. 

In the example (Fig. |4(b)| i, when c2 identifies loop hicli, it informs ri that they are 
both involved in loop /iicli. Since ri has no more clauses to evaluate, it returns an empty 
set of answers to c2 notifying it that membe rOfAlpha( ri,X) is in loop hicli. The further 
evaluation of memberOfAlpha(c2,X) leads to the identification of loop hi and to a new 
answer memberOfAlpha(c2,alice), which is sent first to ri in the context of loop hicli. 
In turn, ri computes answer memberOfAlpha( ri,alice) and sends it to c2. Now, a fixpoint 
for loop /iicli has been reached and c2 sends memberOfAlpha(c2,alice) to cl notifying it 
that memberOfAlpha(c2,X) is in loop hi. Notice that memberOfAlpha(c2,X) is also in loop 
ft-icli, but since this loop does not involve cl, cl is not notified of it. Next, cl computes 
answers memberOfAlpha(cl,alice) and membe rOfAlpha(cl, bob) (the latter being found 
through the evaluation of memberOfAlpha(c3,X)), and sends them to c2 in the context of 
loop hi. In turn, c2 computes membe rOfAlpha(c2,bob) . Now, c2 has to find a fixpoint for 
loop hicli given the new answer before proceeding with the evaluation of loop hi. It is 
worth noting that ri is not aware of loop hi. This is because loop notifications are only 
transmitted to higher requests (except for the lower request that has formed the loop). 

Loop Termination. The termination of the evaluation of all the goals in an SCC is initi- 
ated by the principal handling the leader of the SCC when a fixpoint for the loop it co- 
ordinates has been reached. In the example, when the answers of memberOfAlpha(c2,X) 
do not lead to new answers of membe rOfAlpha(cl,X), cl informs c2 (which in turn in- 
forms ri) that the evaluation of memberOfAlpha(cl,X) is terminated and sends answers 
memberOfAlpha(cl,alice) and memberOfAlpha(c\,bob} to h. 

Side Requests. So far we have only considered "linear" loops, i.e., loops formed by lower 
requests. However, higher requests can also lead to a loop. Consider, for instance, the 
following additional clause stored by company c3: 

8. memberOfAlpha(c3,X) ^ memberOfAlpha(ri,X). 

The new (compact) call graph is shown in Fig. |5(a)| Now, the evaluation of goal member- 
OfAlpha(c3,X) by c3 leads to a request for goal memberOfAlpha( ri,X), which is involved 
in loop hicli. ri can identify that the request originates from the evaluation of a goal in 
the same SCC as memberOfAlpha( ri,X), since the request identifier hicl2c3i is side of 
the identifier hiclic2i of the initial request for membe rOf Alp ha(ri,X) (i.e., /iiclic2i ^ 
hicl2c3i). However, it cannot identify the loop in which the goal evaluated by c3 is in- 
volved. This is because loop notifications are only transmitted to higher goals, and thus 
ri is not aware of loop hi. We refer to the request from c3 as side request, and we call 
memberOfAlpha( c3,Xj a side goal. 

The main problem with side requests is that it is difficult to determine when they should 
be responded to. For example, if ri sends answers to c3 at every iteration of loop /iicli, 
cl would not know when to stop waiting for answers from c3 (since cl does not know 
on which goals memberOfAlpha(c3,X) depends). On the other hand, ri cannot wait until a 
fixpoint is reached for loop hicli, since only c2 (the principal handling the coordinator) 
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(b) Unfolded Call Graph 

Fig. 5. Call Graphs for Side Requests 



is aware of that. To enable the detection of termination, however, a side request should 
be responded to only when a fixpoint is computed for all the loops lower than the loop in 
which the side goal is involved. 

A simple yet effective solution to this problem is to treat a side request for a goal as 
a "new" request (i.e., a request for a goal that has not yet been evaluated) and to reeval- 
uate the goal. Accordingly, when a side request is received, GEM creates a new partial 
derivation tree for the goal and proceeds with its evaluation. This corresponds to inspect- 
ing multiple times some branches of the call graph of the program (Fig. |5(bj] i; however, it 
allows us to obtain a call graph formed only by linear loops which, as shown previously 
in this section, can be successfully evaluated by GEM. Notice that, despite in the unfolded 
graph in Fig. |5(b)| some nodes and edges are duplicated with respect to the folded graph 
in Fig. |5(a)[ the flow of answers among goals is equivalent. This can be easily seen by the 
fact that edges connect the same nodes in both call graphs. In Section 2] (Theorem[3]l we 
show that a call graph is always finite. 

Even though possible in theory, we expect side requests not to occur frequently in the 
evaluation of a policy. For instance, no side request was present in any of the example poli- 
cies in the literature. Therefore, we believe the overhead imposed by the proposed solution 
to be negligible in practice. Nevertheless, we point out that the size of the unfolded graph 
is in the worst case exponential with respect to the number of nodes in the original graph. 
The reevaluation of side requests, in fact, resembles the approach adopted by SLD resolu- 
tion, which reevaluates every goal encountered during a computation. However, thanks to 
our ability to detect loops, the number of goals evaluated by GEM during a computation is 
never higher than the number of goals that would be evaluated using SLD resolution. 

Since we treat side requests in the same way as new requests, the partial order ^ is 
not exploited by the version of GEM presented here. An alternative solution that prevents 
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the reevaluation of side requests and thus requires their identification could be achieved 
by transmitting loop notifications to the requesters of both higher and lower requests, so 
that all the principals evaluating a goal in an SCC would be aware of the identifiers of 
all the loops in the SCC. Furthermore, when a fixpoint for a loop is reached, the principal 
handling the loop coordinator should start a new loop iteration to inform all the goals in the 
loop that the fixpoint has been reached. These two modifications would enable principals 
that receive a side request to know (a) in which loop the side request is involved, and (b) 
when to reply to the side request, that is, when all the loops lower than the one in which 
the side goal is involved have reached a fixpoint. Given the complexity of the solution, in 
this paper we present only the "basic" version of GEM, which reevaluates side requests; 
the implementation of the described optimization is subject of future work. 

To conclude, we point out that evaluating every higher request for a goal that is not yet 
completely evaluated is fundamental for enabling loop detection. Consider, for instance, 
a global policy consisting only of clauses 1 and 6 on pages 8 and 9 respectively. As- 
sume that hospital h issues at the same time a request for goals memberOfAlpha(c\,X) 
and memberOfAlpha(c2,X) with identifier idi and id2 respectively. The evaluation of the 
request by principals cl and c2 leads to a higher request for goals memberOfAlpha(c2,X) 
and memberOfAlpha(c\,X) respectively. When these second higher requests are received, 
a partial derivation tree for the requested goals already exists. If the requests were not fur- 
ther processed, the loop identification would not be possible as no lower request would be 
issued, and the computation would deadlock. Therefore, both initial requests must be pro- 
cessed independently. This "problem" is common to all the distributed goal evaluation al- 
gorithms whose termination detection exploits request identifiers (e.g., jAlves et al. 20061) ). 
Even though relatively simple solutions to this problem can be found (e.g., using times- 
tamped requests, where only the oldest is evaluated), in this paper we focus on a "basic" 
solution for distributed goal evaluation, and do not address efficiency-related issues. 

3.3 Implementation 

Here, we introduce the data structures and procedures used by GEM to evaluate a goal. 

Data Structures. In GEM, principals communicate by exchanging request and response 
messages. We rely on blocking communication, that is, whenever a principal a sends (re- 
spectively receives) a request or response message, no other operation is performed by a 
until the sending (resp. receipt) process is completed. In addition, we assume that a mes- 
sage sent by principal a to a principal h is always received (once) by principal 6. 

Definition 6 

A request is a triple {id,req, G), where: 

• id is the request identifier; 

• req is the principal issuing the request, called requester; 

• G is a goal <— p{loc, ti, . . . , i„), where loc is a constant. □ 

A request is an enquiry issued by principal req for the evaluation of goal G. Each request 
is uniquely identified by an identifier id and is sent to the principal defining G. 
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Definition 7 

Let r = {id,req, G) be a request. A response to r is a tuple {id,Ans, Sans, Loops), where: 

• id is the response identifier; 

• Ans is a (possibly empty) set of answers of G; 

• Sans G {active,loop{idi), disposed} is the status of the evaluation of G, where idi 
is a loop identifier; 

• Loops is a set of loop identifiers. □ 

A response has the same identifier of the request to which it refers. It contains a (pos- 
sibly empty) set of answers of the requested goal G (Ans) together with the status of G's 
evaluation (Sans) and information about the loops in which it is involved (Loops). Sans is 
disposed if G has been completely evaluated, active if additional answers of G may be 
computed, and loop{idi) if the response is sent in the context of the evaluation of loop idi. 

As discussed in Section l372l GEM computes the answers of a goal by a depth-first eval- 
uation of its partial derivation tree (Definition [U, which may involve the generation of 
requests for subgoals evaluated at different locations. In the implementation, we repre- 
sent a partial derivation tree as a data structure called evaluation tree. Compared to partial 
derivation trees, an evaluation tree keeps track of the identifier of the request and status of 
the evaluation of the selected atom of each node in the evaluation tree. 

Definition 8 

A node is a triple {id, c, S), where: 

• id is the node identifier; 

• c is a clause; 

• S* G {new, active, loop{ID), answer, disposed} is the status of the evaluation of 
the selected atom in c, where ID is a set of loop identifiers. □ 

The status of a node is new if no atom from the body of c has yet been selected for 
evaluation. It is set to active when a body atom is selected, and to disposed when the 
selected atom is completely evaluated. The status is set to loop(ID) if the selected atom is 
involved in some loops, where ID is the set of identifiers of those loops, and to answer 
if c is a fact. As mentioned in Section |2] we employ the leftmost selection rule. Thus, the 
selected atom of c is always the first body atom. 

Definition 9 

The evaluation tree of a goal G = <— ^ is a tree with the following properties: 

• the root is node (ido, A ^ A, Sq); 

• there is an edge from the root to a node {idi, {A ^ Bi, . . . , Bn)0, Si), where 
idi C ido, iff there exists a derivation step (A <— A) A (A <— . . . , Bn)0 in the 
partial derivation tree of G; 

• there is an edge from node {id2,A ^ Bi, . . . , _B„, ^2) to node {ids, {A B2, . ■ . , 
Bn)S, S3), where 1^2 C ido and id^ □ ido, iff there exists a derivation step {A ^ 
Bi, . . . , Bn) A [A ^ B2, ■ . ■ , Bn)0 in the partial derivation tree of G; □ 

When a principal receives a higher request for a goal G, it creates a table for G. A table 
contains all the information about the evaluation of G. 
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Definition 10 

The table of a goal G, denoted TahleiG), is a tuple (HR,LR,ActiveGoals,AnsSet, Tree), 
where: 

• HR is a higher request for G; 

• LiZ is a set of lower requests for G; 

• ActiveGoals is a set of pairs (id, counter) where id is a loop identifier and counter 
is an integer value; 

• AnsSet is a set of pairs {ans, ID) where ans is an answer of G and ID is a set of 
request identifiers; 

• Tree is the evaluation tree of G. □ 

The table of a goal G stores the higher request HR for which it has been created, the 
set of answers computed so far (AnsSet), and the evaluation tree of G (Tree). Possible 
lower requests for G are stored in LR. ActiveGoals keeps a counter for each loop in which 
G is involved. The counter of a loop id indicates the number of subgoals of G which are 
involved in loop id, i.e., the number of nodes in Tree with status loop{ID) such that id e 
ID. The counter is decreased whenever an answer of one of these subgoals is received. 
The status of the root node of Tree indicates the status of the evaluation of G. When G is 
completely evaluated, the fields of its table are erased, but the answers of G are maintained 
to speed up the evaluation of future requests for G. 

Procedures. To initiate the evaluation of a goal G, a principal a generates a unique se- 
quence of characters ido and sends a request {ido,a,G) to the principal defining G. A 
response {idQ,Ans, disposed, {}) is returned to a when the evaluation of G terminates. 
GEM computes the answers of G (defined in policy Pq) using the following procedures: 

• Process Request: if the request is not a lower request, invokes Create Table 
to initiate the evaluation of G. Otherwise, it sends a loop notification to the requester; 

• Create Table: creates a table for G and initializes its evaluation tree with the 
applicable clauses in Pq', 

• Activate Node: activates a new node in the evaluation tree of G; 

• Process Response: processes the answers received for a subgoal of G; 

• Generate Response: determines the requesters of G to whom a response must 
be sent. It is invoked when there are no more nodes in the evaluation tree of G to 
activate; 

• Send Response: sends the computed answers of G to the requesters of G; 

• Terminate: disposes the table of G. It is invoked when G is completely evaluated. 

Each principal in the trust management system runs a listener that waits for incom- 
ing requests and responses. Whenever a request is received, the listener invokes PROCESS 
Request. Similarly, Process Response is invoked upon receiving a response to a pre- 
viously issued request. The interactions and dependencies among the different procedures 
are shown in Fig.|6] 

Process Request (Algorithm [TJ takes as input a request {ido,req,G) and, if there 
exists no table for a variant of G, invokes procedure CREATE Table to create a table 
for G (lines 11-12). If another request for goal G (or a variant of G) has been previously 
received, three situations are possible: 
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Fig. 6. Interaction among the Procedures for the Evaluation of a Goal G 



Algorithm 1: Process Request 

input: a request (ido, req, G) 

1 i[3Table{G') = {{idi,req' ,G'), LR,AG,AS,T) s.t. G' is a variant of G then 

2 let Sroot be the status of the root node of T 

3 if Sroot = disposed then 

4 Send RESPONSE((ido, rety, G'), disposed, {}) 

5 else if ido n idi then 

6 LR:=LRU{{ido,req,G')} 

7 Send RESPONSE((irfo, re^, G'), active, {idi}) 

8 else 

9 let G" be a variable renaming of G s.t. flTable{G") 

10 Create TABLE((i(io, G">) 

11 else 

12 Create TABLE((j(io, ''eg, G)) 



1. The request refers to a goal which has been completely evaluated (lines 3-4). A re- 
sponse with the answers of G is sent to the requester by invoking Send Response. 

2. The request is a lower request for G (lines 5-7). This corresponds to the detection of 
a loop idi, where idi is the identifier of HR. The request is added to the set of lower 
requests LR and the answers computed so far are sent to the requester together with 
a notification about loop idi, initiating the loop processing phase. 

3. The request is a side request or originates from a different initial request (lines 8- 
10). We treat the request as a new request; accordingly, a new table for G is created 
by invoking CREATE Table. 

Create Table (Algorithm|2]i inputs a request {ido , req, G) and creates a table for goal 
G with HR set to {ido, req, G), and Tree initialized with the clauses in the local policy 
applicable to G (renamed so that they share no variable with G) (lines 1-7). The identifiers 
of the subnodes of the root are obtained by concatenating ido with a unique sequence of 



GEM: a Distributed Goal Evaluation Algorithm 



19 



Algorithm 2: Create Table 

input: a request (ido, req, G = A) 

1 create Table{G) 

2 initialize Table{G) to ({ido,req, G), {}, {}, {}, {ido, A <- A,new)) 

3 foreach clause H <— Si , . . . , Bn applicable to G in the local policy do 

4 let H' <— , . . . , B'„ be a variable renaming of the clause s.t. it is variable disjoint from A, and 
e = mgu{A,H') 

5 let s be a unique sequence of chai'acters 

6 add subnode {idos, (H' <— , . . . , B!^)6, new) to the root 

7 end 

8 Activate Node(G) 



Algorithm 3: Activate Node 

input: a goal G = A 

1 let Tahle{G) be {HR, LR, AG, AS, T) 

1 if a non-root node t G T with status new) or {(A, ID) G AS) then 

3 Generate Response(G) 

4 else 

5 let Sroot be the status of the root node of T 

6 if Sroot = new then 

7 Sroot '■ = active 

8 select the leftmost non-root node t = {idi , H -f- Bi , . . . , Bn , new) from T 

9 if n = tlien 

10 set the status of t to answer 

11 if H is not subsumed by any answer in AS then 

12 AS ■.= ASU{{H,'{})} 

13 Activate Node(G) 

14 else 

15 if the location of B\ is not ground then 

16 halt with an error message /* floundering */ 

17 else 

18 set the status of t to active 

19 send request (idi, local, Bi) to the location of Bi 



characters s. When the initiaHzation of the table of G is terminated, ACTIVATE Node is 
invoked (line 8). 

Activate Node (Algorithm [3]) activates a new node from the evaluation tree of a 
goal G. First, it sets the status of the root node of the evaluation tree T of goal G to active 
(lines 5-7). Then, a node with status new is selected from T (line 8). If the node's clause is a 
fact and represents a new answer, it is added to the set of answers AS (with an empty set of 
recipients), and ACTIVATE Node is invoked again (lines 9-13). The answer subsumption 
check (line 11) is important to avoid sending the same answers of a goal more than once. 
If the clause is not a fact, the leftmost body atom Bi of the node's clause is selected for 
evaluation. In case that the location parameter of Bi is not ground, an error is raised and 
the computation is aborted by floundering (lines 15-16). Otherwise, a request for Bi is sent 
to the corresponding location; the node identifier is used as request identifier (lines 17-19). 
If there are no more nodes with status new, or G is in the set of computed answers AS, 
Generate Response is invoked (Unes 2-3). 

Send Response (Algorithm HJi inputs a request, a response status, and a set of loop 
identifiers and sends a response message to the requester, which includes the answers of G 
that have not been previously sent to that requester (lines 3-7). 
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Algorithm 4: Send Response 

input: a request {ido, req, G), a response status Sans, a set of loop identifiers Loops 

1 let Table{G) be {HR, LR, AG, AS, T) 

2 Ans := {} 

3 foreach {ans, ID) G AS s.t. ida ^ ID do 

4 Ans := Ans U {ans} 

5 /D := ID U {ido} 

6 end 

7 send response {idoi^«>s, Sans , Loops) to ijeq 



Algorithm 5: Process Response 

input: a response (ido i '^'"'i Sana , Loops) 

1 let t = {ido, H <~ Bi, . . . , Bn, St) be the node in the evaluation tree of goal G = A to which the 
response refers 

2 let Table{G) be {HR, LR, AG, AS, T) 

3 let {idi, A <— A, Sroot) be the root node of T 

4 If Sroot ^ disposed then 



5 if Sans = disposed then 

6 if 5t = «oop(/D) then 

7 dispose all the nodes in T involved in any loop 

8 St ■ = disposed 

9 else 

10 if 5t = «oop{/D) then 

11 ID := ID U Loops 

12 else if Loops ^ {} then 

13 St '■= loop{Loops) 

14 AG := AG U {{id2,0)\id2 g Loops and {id2,c) f AG} 

15 if 5ans = loop{id:j) then 

16 decrease the counter of id^ in AG by 1 

17 if Sroot = active then 

18 Sroot ■■= loop{{ida}) 

19 foreach ans G Ans do 

20 let ans' be a variable renaming of ans s.t. it is variable disjoint from Bi, and 6 = mgu{Bi , ans') 

21 let s be a unique sequence of characters 

22 add subnode {idis,{H B2, . . . ,Bn)d, new) oft 

23 end 

24 it (Sroot = active) or (Sroot = loop{ID) anAMidi G ID, {id4,0) G AGJ then 

25 Activate Node(G) 



Response messages are processed by PROCESS Response (Algorithm |5]i. The node t 
to which the response refers is identified by looking at the response identifier (line 1). If 
the status of the response is disposed, the selected atom Bi of t is completely evaluated. 
Therefore, t is disposed and, if Bi is in a loop, also all the other nodes in any loop of the 
sec are disposed (lines 5-8). This is because the termination of a loop is ordered by the 
principal handling the leader of the SCC once all the goals (and consequently, all the loops) 
in the SCC are completely evaluated. 

Otherwise, the status of t is updated depending on whether the response contains a loop 
notification, i.e., set Loops contains some loop identifier (lines 10-13). In this case, an 
entry is added to the set of active goals AG for each new loop in Loops (line 14). If the 
response has been sent in the context of the evaluation of a loop id^, the counter of id^ in 
AG is decreased and the status of the table is changed to loop{{id3}) (lines 15-18). 
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Algorithm 6: Generate Response 

input: a goal G = A 

1 let Table{G) be {HR, LR, AG, AS, T) 

2 if {^(idc),c,«oop(/D)) G T) then 

3 Terminate(G) 

4 else 

5 let (id\ , A <— A, Sroot) be the root node of T 

6 if G « f/te coordinator of a loop id\ and 3ans g AS .s.f. ans Ims not been sent to some request in LR 
then 

7 set the counter of id\ in AG to the number of subgoals in T involved in loop id\ 

8 ii Sroot = loop(ID\) then 

9 Sroot ■■= loop{IDi U 

10 else 

11 Sroot ■■= loop{{idl}) 

12 foreach {id2,req,G) G L-R do 

13 Send RESP0NSE{(ic(2, re^, G),loop{idi), {}) 

14 end 

15 else if G « f/ie leader of the SCC then 

16 Terminate(G) 

17 else 

18 let Loops be the set {idsKsfia, G) € AG and icii CI ids} 

19 set the counter of each ids G Loops to the number of subgoals in T in loop ids 

20 if 5root = loop(IDi) and 3irf4 G /Di i./. idi IZ id^ then 

21 Send Response{H_R, loop{id4). Loops) 

22 else 

23 Send RESPONSE{i?_R, active. Loops) 

24 Sroot := active 



After updating the node and table status, the set of answers in the response is processed 
(lines 19-23). In particular, a new subnode of t is created for each answer The clause of 
the new node is {H ^ B2, ■ ■ ■ , Bn)0, where 6 is the ragu of Bi and the answer, and 
its identifier is obtained by concatenating the identifier idi of the root node of T with a 
unique sequence of characters s. When all answers have been processed, if the principal is 
not waiting for a response for any subgoal in the evaluation tree of G, ACTIVATE Node is 
invoked to proceed with the evaluation of G (line 25). 

Generate Response (Algorithm |6]i is invoked when all the clauses in the evaluation 
tree of a goal G (except for the ones in a loop) have been evaluated. If G is not part of a 
loop. Terminate is invoked (lines 2-3). Otherwise, we distinguish three cases: 

1. If set LR is not empty, then goal G is the coordinator of a loop idi, where idi is the 
identifier of the higher request for G. If there are new answers of G that have not 
yet been sent to the lower requests in LR, a response with status loop{idi) is sent to 
each of them (lines 6-14). This corresponds to starting a new loop iteration for loop 
idi. The status of the root node of the evaluation tree T is updated to keep track of 
the loops that are currently being processed (lines 8-11) and the counter of idi in 
the set of active goals AG is set to the number of subgoals in T involved in loop idi 
(i.e., the number of nodes with status loop{ID) such that idi £ ID, line 7). This 
number corresponds to the number of subgoals for which a response in the context 
of loop idi will be returned. 

2. If G is the leader of the SCC and no new answers of G have been computed, the loop 
is terminated by invoking TERMINATE (lines 15-16). G is the leader of the SCC if 
the only loop identifier in set AG is the identifier of the higher request for G. 
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Algorithm 7: Terminate 

input: a goal G 

1 let TaUe{G) be {HR, LR, AG, AS, T) 

2 dispose all non-answer nodes in T 

3 foreach {ido,mq, G) € {HR} U LR do 

4 Send RESPONSE{(i(io,»"eg, G), disposed, {}) 

5 end 

6 ffij := nitii 

7 LiJ := AG := {} 



3. Otherwise, a response including the identifier of the loops in which G is involved 
is sent to the requester of HR (lines 18-24). The status of the response depends on 
whether HR is involved in one of the loops currently being processed (lines 20-23). 

Terminate (Algorithm|7]i is responsible of disposing a table once all the answers of its 
goal G have been computed. More precisely, all the table fields are erased except for the 
set AS of answers of G, which are kept in case of future requests for goal G. A response 
with status disposed is sent to the requesters of HR and LR (lines 3-5). 

An example of execution of GEM is in Appendix B. 



4 Properties of GEM 

This section presents the soundness, completeness and termination results of GEM. More- 
over, we discuss what information is disclosed by GEM during the evaluation of a goal. 



4.1 Soundness, Completeness and Termination 

Here, we refer to an arbitrary but fixed set Pi , . . . , P„ of policies, and to the corresponding 
global policy P = Pi U . . . U P„ . To prove its soundness and completeness, we demonstrate 
that GEM computes a solution if and only if such a solution can be derived via SLD reso- 



lution, which has been proved sound and complete ( Apt 1990 1. The proofs of the theorems 
presented in this section are provided in Appendix A. 

The following theorem states that each solution computed by GEM can also be derived 
via SLD resolution using the global policy P, and is thus correct. Intuitively, this is due to 
the fact that the solutions generated by the algorithm are obtained using the clause resolu- 
tion mechanism, which produces correct results. 

Theorem 1 {Soundness) 

Let Gi be a goal. Let S be the set of tables resulting from running GEM on Gi (w.rt. 
P = Pi U . . . U P„). Let Gi , . . . , G/j be the goals for which there exists a table in S. For 
each goal Gi G {Gi, . . . , Gfc} let SoU = {6li_i, 6'^,^; } be the (possibly empty) set of 
solutions of Gi generated by the algorithm. Then, for each Gi S {Gi, . . . , G^} and for 
each Oi^j G SoU there exists an SLD derivation of P U {Gi} with c.a.s. a s.t. GiOij is a 
renaming of Gicr. 



Next, we present the completeness result. 
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Theorem 2 {Completeness) 

Let Gi be a goal. Let S be the set of tables resulting by running GEM on Gi (w.r.t. P = 
Pi U . . . U Pn). Assume that running GEM on d (w.r.t. P = Pi U . . . U P„) did not result 
in floundering. If there exists an SLD derivation of PU {Gi} with c.a.s. 6, then there exists 
a solution a of Gi in S s.t. Gif? is a renaming of Giu. 

Finally, we state that GEM always terminates. 

Theorem 3 (Termination) 

Given a goal G evaluated w.r.t. a finite global policy P, GEM terminates. 

4.2 Disclosed Information 

A primary objective of GEM is to preserve the confidentiality of intensional policies. Here, 
we discuss what policy information principals are able to collect during the evaluation of a 
goal, and classify GEM according to the confidentiality levels defined in Section |2] 

First, let us define the following notation. Let P be a global policy, and Ga and Gf, be 
two goals in P defined by principals a and h respectively. We say that goal Ga depends 
on goal Gf, if there is a path from Ga to Gb in the call graph of the evaluation of Ga with 
respect to P. Since each edge in the call graph represents a request in GEM, and in trust 
management each request corresponds to a delegation of authority, if Ga depends on Gb 
then we say that there is a chain of trust from principal a to principal b. 

We also introduce some notation on request identifiers. As mentioned in Section 13.21 
the identifiers in an identifier domain can be defined in several ways (e.g., applying a 
hash function to the identifier of a higher request). In this paper, we have considered an 
identifier domain where identifiers are obtained by concatenating the identifier of a higher 
request with a sequence of characters. Here, we discuss what information is disclosed by 
GEM during goal evaluation using this identifier domain. We classify identifiers obtained 
by concatenation according to two dimensions: traceability and length. Given two request 
identifiers idi and id2 for goals Gi and G2 respectively, such that 1^2 C idi, the traceabil- 
ity dimension refers to the ability of a principal to infer which principals are involved in 
the evaluation of the goals in the path from Gi to G2 . On the other hand, the length dimen- 
sion defines the ability to determine the number of goals in the path from Gi to G2. Let 
id^si ■ • • s„ be a request identifier, where id^ is the identifier of the initial request and each 
Si (for i G {!,..., n}) is a sequence of characters added by a principal to the identifier 
id^si ■ ■ ■ Si^i of a higher request. For what concerns the traceability dimension, we say 
that idosi ■ • • s„ is a traceable identifier if each string Si uniquely identifies (the location 
of) principal pi (as done, for instance, by the identifiers in the example in Section I3.2l i: 
otherwise, we say that identifier id^si • • ■ s„ is untraceable. The length dimension is de- 
fined based on the number of characters concatenated by each principal pi to the request 
identifier idpsi • • • Si-i. Let len{si) denote the number of characters in the string s^. If 
len{si) = . . . = len{sn), then we say that id^si • • • s„ is a fixed-length identifier; other- 
wise, we say that idoSi • • ■ s„ is a variable-length identifier (we assume that cryptographic 
techniques are in place to avoid collision of identifiers ( IHoch and Shamir 2008l l). Note that 
a traceable identifier does not necessarily disclose information about the number of goals 
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in the path between two goals; this is because a goal defined by a principal a can have sev- 
eral subgoals defined in as policy. Consider, for instance, the traceable request identifier 
/i:12cl:345, obtained by concatenating a request identifier with a principal's identifier and 
a variable-length sequence of digits for each goal evaluated by the principal. Even though 
identifier /i:12cl:345 shows that the principals involved in the computation are hospital 
h and company cl, it does not confer information about the number of goals evaluated 
by those principals. Company cl, for example, might have evaluated two locally defined 
goals, concatenating the higher request h:12 received from hospital h first with its identifier 
cl and digit "3" (separated by a semicolon), and then with the sequence of digits "45". 

We are now ready to present what information a principal b is able to learn about the 
local policy of a principal a where a goal Ga is defined. First of all, by requesting the 
evaluation of Ga, b learns the set of answers to the request, i.e., the extensional policy 
relative to Ga', this is necessary for any goal evaluation algorithm. As mentioned in Sec- 
tion[Tl the confidentiality of extensional policies can be protected, for instance, by relying 
on hidden credentials jBradshaw et al. 2004t lFrikken et al. 2006b or trust negotiation algo- 
rithms ( Winsborough et al. 2000^ Winslett 20031 1 . Here, we are more interested in what b 



can learn about the intensional policy defining Ga- 

By sending a request for Ga (say, with identifier idi), b can learn whether Ga depends 
on some goal Gf, defined in her policy. Indeed, if 6 receives a request for Gf, with identifier 
id2 such that ic?2 C idi, then b knows that Ga depends on Gb- 

If Ga depends on a number of goals defined by b, then by requesting Ga b learns: 

• what are the goals Gb^ , • ■ • , Gb„ defined in her policy on which Ga depends; 

• for each Gfc. G {Gb^ , • • ■ , Gb„ }, b knows who is the principal pi that requested Gbi ; 
therefore, b learns that Ga depends on a goal defined by pi, i.e., that there is a chain 
of trust from a to pi (and from pi to b). Principal b, however, does not necessarily 
learn which is the goal defined by pi on which Ga depends; 

• depending on how the identifiers are constructed, b might be able to learn additional 
information about the path from Ga to Gf,, . In particular, if the identifier of the 
request for Gfc. is fixed-length, 6 is able to infer the number of goals in the path 
from Ga to Gh . . Additionally, if the identifier is traceable, b also learns who are the 
principals defining those goals. 

Thus, GEM can be classified as El -II according to the classification criteria in Section |2l 
In fact, principals learn all the answers of a goal along with some dependencies among the 
goals involved in an evaluation. 

We now illustrate the concepts presented above with an example, using the global policy 
introduced in Section [3721 and the call graph shown in Fig. |5(a)| on page 14 (ignore, for 
now, the request identifiers depicted in the figure). Assume that the research institute ri 
requests goal memberOfAlpha(c\,X) to cl. If the identifiers used in the computation were 
variable-length and untraceable, ri would be able to learn that: 

• memberOfAlpha(cl,X) depends on goal memberOfAlpha( ri,X) defined in its policy; 

• memberOfAlpha(cl,X} depends on some goal Gc2 defined in c2's policy and on 
some goal Gc3 defined by c3; however, it does not learn which goals they are. Fur- 
thermore, due to the loop notification received from c2 following the evaluation of 
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Fig. 7. Part of the Call Graph That Can Be Inferred by ri 



goal memberOfAlpha(c2,X), ri learns that memberOfAlpha(c2,X) depends on some 
goal in the path from memberOfAlpha(cl,X) to Gc2- 

Fig. |7(a)| represents r/'s "view" of Fig. |5(a)[ that is, the part of the call graph that ri 
can infer. In the graph, we denote with dots ("...") the predicate symbols and terms that ri 
does not learn; a dashed edge from a goal Gi to a goal G2 indicates that ri is able to infer 
that Gi depends on G2, but not the (number of) goals and principals in the path from Gi 
to G2. Since ri does not learn that Gc2 is actually goal memberOfAlpha(c2,X), with re- 
spect to the call graph in Fig. |5(a)[ in Fig. |7(a)| goal memberOfAlpha(c2,X) is "duplicated". 
The reason why ri is not able to infer that Gc2 is memberOfAlpha(c2,X), and even more, 
does not learn whether memberOfAlpha(c2,X) is in the path from memberOfAlpha(cl,X) 
to membe rOfAlpha( ri,X) or is a lower goal, is that the only information that ri receives in 
response to the request for memberOfAlpha(c2,X) (besides the answers of the goal) is a 
notification that membe rOfAlpha(c2,X) is in a loop, say with identifier idi. ri can observe 
that idi corresponds to a request higher than the request for membe rOf Alp ha(ri,X), i.e., 
that the loop coordinator is higher than memberOfAlpha( ri,X). However, ri cannot infer 
whether the loop was formed by its own request (in which case ri would learn that Gc2 is 
memberOfAlpha( c2,X)), or by a request issued by c2 when evaluating membe rOf Alp ha( c2,X), 
or even by the evaluation of a goal on which membe rOf Alp ha(c2,X) depends. In other 
words, because of the variable-length and untraceable nature of identifiers, ri does not 
know the number of goals in the path from membe rOfAlpha( ri,X) to the loop coordinator. 

In addition to the information above, if the identifiers used in the computations were 
fixed-length, ri would also be able to learn that: 

• one of the paths from memberOfAlpha(cl,X) to membe rOfAlplia(ri,X) consists of 
three goals: memberOfAlpha(cl,X), Gc2, and memberOfAlpha(ri,X). Furthermore, 
ri can infer that Gc2 is the coordinator of loop idi ■ However, ri still does not learn 
whether Gc2 is memberOfAlpha(c2,X); 

• the other path from membe rOfAlpha(cl,X) to memberOfAlpha( ri,X) consists of three 
goals: memberOfAlpha(cl,X), Gcs, and memberOfAlpha( ri,X). 

The part of the call graph that ri can infer in a computation with fixed-length identifiers is 
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Fig. 8. Part of the Call Graph That Can Be Inferred by ri by Issuing Multiple Requests 
Using Fixed-Length Identifiers 



independently from the traceability of the identifiers. This is because ri already knows all 
the principals in the paths from memberOfAlpha(cl,X) to memberOfAlp!ia( ri,X): cl is the 
principal to whom ri sent the initial request, and c2 and c3 are the principals from whom 
ri received the request for memberOfAlpha( ri,X). Even with traceable identifiers, ri would 
not be able to infer more information about the path from memberOfAlpha(c2,X) to Gc2, 
as the only information received by ri from c2 is the loop identifier. 

A principal might attempt to infer a bigger portion of the call graph by issuing requests 
for each goal defined by the principals in the trust management system. For instance, ri 
can infer more information by issuing a request for each goal defined by companies cl, 
c2, and c3. In particular, by issuing a request for memberOfAlpha(c2,X), in a computation 
with fixed-length and traceable identifiers ri would learn that memberOf-Alpha(c2,X) is 
the goal defined by c2 that depends on memberOfAlpha(ri,X) (Fig. |8(aj] ). By also issuing 
a request for memberOfAlplia(c3,X), ri could infer the whole call graph (Fig. |8(b)"| . Note, 
however, that the global policy considered here is a relatively simple policy with few goals 
and principals. A more complex policy would complicate and sometimes prevent the infer- 
ence of goal dependencies. Moreover, some information about the global policy would not 
be deducible by ri when using variable-length and untraceable identifiers. All the edges 
in the call graph in Fig. |8(b)[ for instance, would be dashed edges if variable-length un- 
traceable identifiers were used. Finally, it is worth noting that even though ri might be able 
to learn the whole call graph, that graph might correspond to different intensional poli- 
cies jCostantini 20011) . For example, ri is not able to learn whether memberOfAlpha(c2,X) 
and memberOfAlpha(c3,X) are connected by disjunction or conjunction in el's policy. 

To conclude, we argue that when using an appropriate identifier domain the knowledge 
about goal dependencies disclosed by GEM is not sufficient for a principal b to infer the 
intensional policy relative to a goal Ga defined by a principal a. Principal b always learns 
whether Ga depends on goals defined in her poHcy, but most likely not all the goals in 
the global policy on which Ga depends. Consider, for instance, clause 2 on page 2. A 
principal other than cl and mc cannot learn that memberOfAlpha(cl,X) depends on pro- 
jectPartner(mc,Y). We believe that the information that b can infer is consistent with the 
concept of trust management. In fact, if Ga depends on a goal defined by 6, then there is 



shown in Fig. |7(b)| Note that, in this 
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a chain of trust from a to b; it seems legitimate that the existence of such a chain may not 
remain secret to b. 

5 Practical Evaluation 

We implemented the algorithms presented in Section 13.31 in Java and conducted several 
experiments to evaluate the performance of GEM. In particular, we first tested the imple- 
mentation with the example policies defined in Section [32] and in Appendix B. Then, we 
modified those policies to assess the scalability of GEM with respect to an increase in the 
number of principals in the trust management system and the number of clauses in the 
global policy. 

We carried out the experiments by running GEM on four machines located in different 
area networks. More precisely, we employed two machines located within the Eindhoven 
University of Technology (TU/e) network, and two located at the University of Twente 
(UT). The two TU/e machines mount an Intel Core 2 Quad 2.4 GHz processor with 3 
GB of RAM and a 32 bit Windows operating system. The UT machines are 32 bit Ubuntu 
machines with the same processor but 2 GB of RAM. In each experiment, we have assigned 
approximately one fourth of the principals (i.e., one fourth of the local policies) in the 
global policy to each machine. The exchange of messages between principals on different 
machines is via HTTP ( javax. servlet .http Servlet API). 

To present the results of the experiments, we group them into two sets. The first set of 
experiments (Section 15.11 ) studies the performance of GEM for an increasing number of 
principals, clauses, and loops in the global policy. The second set (Section lS!2] i shows, for 
some of the global poUcies in the first set, the effects of increasing the size of the exten- 
sional policy (i.e., the number of facts in the global policy). For each experiment we report 
the following results: the number of principals involved in the computation (denoted by 
Princ); the number of tables created by GEM during the computation (Tab); the number of 
clauses evaluated (Clauses); the sum of the computation times on the four machines, ex- 
pressed in milliseconds (CTime); the total time (TTime), expressed in milliseconds, given 
by the CTime plus network communication time; the total memory occupied by GEM on 
the four machines, expressed in kilobytes (TMem); the maximum memory occupied by the 
tables of the goals created by GEM on the four machines, expressed in kilobytes (TabMem); 
the memory occupied by the tables of the goals created by GEM on the four machines 
after the tables' disposal, expressed in kilobytes (EndTabMem); the number of requests 
issued during the computation (Req); the number of loops identified during the computa- 
tion (Loops); the number of response messages exchanged between principals (Resp); the 
number of non-empty response messages (i.e., response messages containing at least one 
answer) exchanged between principals (Resp&Ans); the total number of answers computed 
by GEM during the evaluation of the policy (Ans). 

5.1 Experiments Set 1: Increasing the Number of Principals, Clauses, and Loops 

In the first set of experiments we conducted three groups of (sub)experiments to evalu- 
ate the performance of GEM in response to an increase in: (1) the number of principals 
and clauses, (2) the number of loops, and (3) both the number of principals, clauses and 
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loops in a global policy. To evaluate GEM in response to an increase in the number of 
principals and clauses (experiments group 1), we created six variants of the global policy 
in Appendix B. For the second group of experiments, we created six variant of the global 
policy defined in Section [372l Similarly, other six variants of the same policy were created 
for the experiments in the third group, in order to increase the number of both principals, 
clauses, and loops. The call graphs of the six variants of the global policies are shown in 
Fig. C 1 in the appendix. Each variant is denoted by an identifier that goes from x.O to x.5 
(where x is either 1, 2, or 3 depending on the experiment group for which they are used), 
where variant x.O represents the original policy. Notice that, for the sake of compactness. 
Fig. C 1(b) and C 1(c) show the folded graph of the global policies, i.e., they do not repre- 
sent the reevaluation of goals due to side requests. Since in GEM the computation is based 
on the unfolded versions of the graph (e.g., the graph in Fig. |5(b)| on page 14 for variants 
2.0 and 3.0), the number of lower requests occurring in the actual computation is higher 
than the one displayed by the figures. For instance, the number of lower requests for the 
leader of the SCC goes up to seven in variants (and hence experiments) 2.5 and 3.5. 

Table [T] presents the results of the three groups of experiments. Each row in the table 
shows the results for the variant of the global policy with identifier indicated in column ID. 
The total time (TTime) and the computation time (CTime) are the average times for 100 
runs of each experiment; the values in all the other columns are constant for every run, as 
they depend on the structure of the global policy. 

Before interpreting the results of the experiments, let us provide some general comments 
on the relationship between the values in different columns of Table [T] First, in every 
experiment the number of requests (Req) is equal to the number of tables generated (Tab) 
plus the number of loops identified by GEM (Loops); this is because a request is either a 
higher request, which leads to the creation of a table, or a lower request, and thus forms 
a loop. Second, the number of response messages (Resp) is always at least as large as 
the number of requests, since to every request is given a response, even if with an empty 
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set of answers. The number of empty response messages (i.e., response messages with an 
empty set of answers) can be observed by subtracting the number of response messages 
containing at least one answer (Resp&Ans) from the total number of response messages 
Resp. Finally, for some experiments (namely in the computation of variants 2.2 to 2.5 and 
3.2 to 3.5), the number of tables generated by GEM is higher than the number of clauses 
(Clauses) and thus the number of goals defined in the global policy. This is because while 
column Tab reports the total number of tables generated during a computation, column 
Clauses shows the number of different clauses being evaluated. In other words, we do not 
count twice the clauses used for the evaluation of a goal that is reevaluated because of a 
side request. The reason behind this choice is that, on the one hand, we are interested in 
showing the impact of the number of tables generated and answers computed (Ans) during 
the evaluation of a policy on the memory usage {TMem and TabMem); on the other hand, 
considering the number of different clauses gives a better insight on the size of a policy. 

A first interesting outcome of the experiments is that the time and memory results in 
Table [T] increase approximately linearly with the number of loops in the global policy (see 
Fig. C 2 in the appendix of the paper for a graphical overview). When the number of loops 
is low (experiments in groups 1 and 2) the time and memory usage are negligible, but as 
the number of loops increases considerably (experiments group 3), the TTime, TMem, and 
TabMem get substantially higher This is because an increase in the number of loops (es- 
pecially if nested, as in the global policy in Fig. C 1(b) in the appendix of the paper), leads 
to an increase in the number of response messages, answers, and (since GEM reevaluates 
side requests) tables generated in a computation. 

Another interesting result is represented by the difference between total time and com- 
putation time (see Fig. C 2(a) in the appendix). In fact, the TTime ranges from 16.7 times 
the CTime for policy variant 1.5, up to 80.1 times the CTime for variant 2.1. This implies 
that most of the TTime is devoted to network communication. Therefore, we can conclude 
that the larger the number of requests and response messages and the number of answers 
per response message, the higher the difference between TTime and CTime. Furthermore, 
we point out that in a real distributed system where to each principal corresponds a differ- 
ent machine (possibly in a different area network) the TTime would be much higher than 
the results in Table[T] especially when the number of principals increases. 

Finally, Table [T] shows that the number of answers in a computation is always larger 
than the number of response messages containing at least one answer; in other words, each 
message in Resp&Ans carries more than one answer on average. This information, com- 
bined with the observation on the difference between TTime and CTime, suggests that GEM 
can consistently reduce network overhead with respect to other goal evaluation algorithms 
which send one message for each computed answer (e.g., ( lAlves et al. 2006b ). especially 
when the number of principals and facts in the global policy increases. 

5.2 Experiments Set 2: Increasing the Size of Extensional Policies 

In a real- world policy, we expect the size of the extensional policy (i.e., the number of facts 
that can be derived from the policy) to substantially exceed the size of the intensional policy 
(i.e., the number of clauses used to derive new facts). Consider, for example, the students 
of a university: while there are only a few rules that define the procedure for becoming 
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a student, the number of students usually goes beyond several thousands. The goal of the 
experiments presented in this section is to evaluate the impact on the performance of GEM 
of an increase in the number of facts in a global pohcy. To this end, we considered some 
of the global policies introduced in Section ISTI and increased the size of their extensional 
policies by a factor of 10, 50, and 100; in particular, we modified variants 1.0, 1.5, 2.0, 
2.5, and 3.2. We could not perform experiments on variants 3.3 to 3.5 due to the limited 
memory available on some of the machines used in the experiments. 

Table |2] shows the results of the second set of experiments. In the table, suffix "a" on 
a variant's identifier indicates an increase by a factor of 10 of the number of facts in that 
variant of the global policy, suffix "b" indicates an increase by a factor of 50, and suffix "c" 
indicates an increase by a factor of 100. Note that the number of answers (Ans) computed 
on variants 1.0 and 1.5 grows less than a factor of 10, 50, and 100 because, in order to not 
modify the structure of the global policy, the number of facts in the policies of principals 
mcl to mc6 in Fig. C 1(a) in the appendix was not increased; more precisely, those policies 
always consists of only two facts. Similarly to the previous experiments, TTime and CTime 
are the average times for 100 runs of each experiment. 

The results in Table|2]show that memory usage {TMem and TabMem) and computation 
time grows faster than the other values for policies with a very large number of computed 
answers (i.e., variants 1.5c, 2.5c, and 3.2c). For what concerns memory usage (Fig. C 3(b) 
in the appendix of the paper), the extra overhead is due to the accompanying increase of 
the information that needs to be stored in tables (i.e., clauses, loops, answers). After the 
disposal of the tables employed in the computation, there is a decrease of up to 38% of 
the memory usage (EndTabMem). This suggests that it is very important to delete as much 
information as possible from the table of a goal when the goal is completely evaluated, 
as this leads to a substantial reduction of memory usage. In this respect, GEM has the 
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advantage of enabling principals to detect when the evaluation of the single goals involved 
in a computation is completed, and immediately clean up the table of those goals. 

Further to the increase in the number of exchanged messages, we believe the extra over- 
head in TTime and CTime in computations with a large number of answers (the peaks for 
variants 1.5c, 2.5c, and 3.2c in Fig. C 3(a) in the appendix) to be due to the growth of the 
data structures used by GEM to search, for example, for new answers and clauses to be 
activated. In addition, contrarily to experiments set 1, in this set of experiments the TTime 
is not always dominated by network communication time. In particular, for variant 1 .5c the 
CTime is twice the network time, and for variant 1.5b the CTime is slightly larger than the 
network time. In the remaining experiments the TTime ranges from 2.2 times the CTime 
for policy variant 3.2c, up to 77.7 times the CTime for variant 2.0. Moreover, note that 
the difference between TTime and CTime always decreases as the number of facts grows. 
This is due to the fact that the number of messages exchanged between principals remains 
constant while the size of the extensional policy is increased. 

To conclude, we highlight again how the "wait" mechanism that GEM employs to col- 
lect a maximum set of answers before sending a response can contribute to reduce the 
network overhead, especially for global policies with a large extensional policy. For exam- 
ple, in the experiment on variant 3.2c, GEM sends "only" 196 response messages, while 
other distributed goal evaluation algorithms (e.g., (lAlves et al. 2006l l) would send 38400 
messages, one for each computed answer. Intuitively, the latter approach would lead to a 
network communication time much higher than the 7.5 seconds spent by GEM. 



6 Dealing with Negation 

GEM is devised to work with definite logic programs, i.e., programs without negation. 

Negation is used by some trust management systems (e.g., jCzenko et al. 20061 Dong and Dulay 2010 1) 



to express non-monotonic constraints, such as separation of duty or "distrust" in principals 
with certain attributes (e.g., employees of a rival company). Here, we discuss how GEM 
can be extended to support the use of negation as failure. 

Negation as failure is an inference rule that derives the truth of a negated body atom 
not{B) by the failure to derive B. The problem when allowing the use of negation (as fail- 
ure) is that in the presence of loops through negation (i.e., loops involving negated atoms) 
a program may have several minimal models (IGelfond andLifschitz 1988] l. For instance, 
program p 4- not{q), q ^ not{p) has two minimal models: {p} and {q}. Moreover, 
these two models are not well-founded JVan Gelder et al. 199I| l. as there is no clause in 
the program demonstrating that p respectively q are true. Another undesired consequence 
of loops through negation is that they may introduce "inconsistencies" in a program, as 
shown at the end of this section. There are additional consequences of loops through nega- 
tion ( [Apt and Bol 1994] IVan Gelder et al. 1991b . which we do not discuss further as they 
go beyond the scope of this paper. In fact, our goal is not to have a full-fledge handling 
of negation, but to allow the use of negation in policies while preventing loops through 
negation. 

Loops through negation are a well-studied issue in the logic programming literature. 
There are three standard solutions to the problems they raise: (a) forbidding the presence of 



loops through negation, as done by the weakly perfect model semantics ( Przymusinska and Przymunsinski 1 990 1 
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which is defined only for weakly stratified programs (that include locally stratified ( Przymusinski 1988 1 



and stratified programs (Apt et al. 1988 1); (b) using a three-valued semantics ( Przymusinski 199^ , 



including the truth value undefined next to true anA false, as done by the well-founded se- 
mantics (IVan Gelder et al. 199 It and Fitting's semantics (Fitting 1985 1, where the seman- 



tics of p in the program p <— not{p) is undefined; (c) following a multi-model approach, 
as in stable models (IGelfond andLifschitz 1988] l. 

Our solution follows an approach similar to (a), since solutions (b) and (c) are not suit- 
able for trust management systems. In fact, relying on a three-valued semantics (b) requires 
additional mechanisms to determine whether the truth value of the goals involved in a loop 
through negation is true, false, or undefined (e.g., delaying in SLG resolution dChen and Warren 1996l l). 
In trust management, however, loops through negation are inherently wrong, as they indi- 
cate conflicting policy statements issued by principals among which there is a mutual trust 
relationship, and thus should not be processed. Similarly, solution (c) would imply that an 
access request should be either granted or revoked depending on which (truth) value we 
"choose" to assign to the goals in a computation, which is clearly not a safe approach. So- 
lution (a) can also not be applied straightforwardly in our context because the definition of 
weakly stratified program relies on a "global ordering" among all the (ground) atoms in a 
global policy. This would require principals to agree beforehand on the allowed dependen- 
cies among (ground) goals; however, in a trust management system principals often do not 
know each other until their first interaction. Therefore, rather than forbidding the presence 
of loops through negation, we prevent their evaluation. In this respect, the added value of 
GEM is its ability to detect loops at runtime. We exploit this feature by introducing an 
additional runtime check to the algorithm, which causes the computation to flounder if a 
loop involving a negated goal is detected. The check is safe in that if the computation does 
not flounder, then it always returns a correct answer. 

In summary, GEM can be extended to allow the use of negation in policy statements as 
follows. Given a clause with a literal not{B) selected for evaluation: 

1. if i? is not ground, an error is raised and the computation flounders; 

2. if the evaluation of B succeeds with an answer, then not{B) fails and the clause is 
disposed; 

3. if B is completely evaluated and has no answers, then not{B) succeeds and a new 
node is added to the evaluation tree of the goal, removing not{B) from the body; 

4. if a loop notification for atom B is received, an error is raised and the computation 
fiounders. 

Conditions (1), (2) and (3) are standard when defining negation as failure: (1) is necessary 
to guarantee correctness ( |Apt 1990| , while (2) and (3) define the semantics of negation. 
Notice that condition (3) captures also the case of infinite failure, as done, for instance, 
by the well-founded semantics (IVan Gelder et al. 19911 1. For example, given a policy com- 
posed of clauses q <— not{p) and p <— p, and a goal q, GEM first completely evaluates 
clause p p, detecting the loop and deducing that no answer of p can be derived; con- 
sequently, it concludes that q is true. Condition (4) states that the algorithm flounders if it 
detects a loop through negation. The "floundering message" is propagated to all the goals 
involved in the loop similarly to a response message, so that their evaluation is aborted. 
Note that floundering due to condition (1) can be avoided by restricting to well-moded 
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programs ( Apt and Marchiori 1994 1. Differently from weakly stratified programs, which 
require an ordering among all the goals in a global policy, the definition of well-moded 
program requires each clause independently to be well-moded. Therefore, by requiring 
local policies to be well-moded, this type of floundering can be prevented. 
It is straightforward to demonstrate that the proposed extension of GEM: 

• always terminates (for arbitrary global policies and requests), because the only dif- 
ference with the standard GEM algorithm (which terminates) is the presence of an 
additional termination condition, and 

• for non-floundering computations, it is sound and complete with respect to the stable 
models and well-founded semantics. 

We now show how the extended algorithm deals with negation by means of an example. 
We consider a scenario inspired by the one introduced in Section[T] where the pharmaceu- 
tical company cl needs to determine the set of principals participating to project Alpha. 
Project Alpha is a multidisciplinary project which requires the collaboration of experts 
from several fields: physicians, biologists, chemists, etc. Company cl already formed a 
team of qualified chemists to work on the project, and delegates to the partner company 
c2 the authority of determining the remaining project members. To avoid interference with 
the work of its trusted chemists, however, cl wants to prevent chemists of c2 to take part 
to the project. In its definition of project members, c2 includes also the members of project 
Alpha at cl. This scenario can be represented by the following policy statements: 

1. memberOfAlpha(cl,X) ^ memberOfAlpha(c2,X), not(chemist(c2,X)). 

2. memberOfAlpha(cl,ciai;id). 

3. chemist(cl,ciai;id). 

4. memberOfAlpha(c2,X) ^ memberOfAlpha(cl,X). 

5. memberOfAlpha(c2,aZice). 

6. chemist(c2,aHce). 

7. memberOfAlpha(c2,er-ic). 

To compute the answers of goal memberOfAlpha(cl,X), GEM proceeds as follows. First, 
clause 1 is evaluated by cl, leading to a request for goal memberOfAlpha(c2,X) to c2. The 
evaluation of the first applicable clause in c2's policy (clause 4) forms a loop, identified 
by cl. The loop processing phase continues at c2, which identifies the first two answers 
of memberOfAlpha(c2,X) (i.e., memberOfAlpha(c2,alice) and memberOfAlpha(c2,eric), 
clauses 5 and 7 resp.) and sends them to cl. For each of these answers, cl requests to 
c2 whether the project member is a chemist. The evaluation of chemist(c2,alice) succeeds 
at c2 (clause 6), while chemist(c2,eric) fails; therefore, their negated counterpart in clause 1 
fails and succeeds respectively, leading to a new answer at cl, namely memberOfAlpha(cl, 
eric). This answer, together with the answer derived by evaluating clause 2 (i.e., memberOf- 
Alpha(c\,davidJ), is sent by cl to c2, starting the second loop iteration. In this iteration, 
c2 finds one new answer, memberOfAlpha(c2,da\'id), which is immediately returned to cl. 
Now, cl evaluates clause 1 based on the new answer received from c2. Since David is not 
a chemist at c2, cl derives again answer memberOfAlpha(cl,da-vid), which had already 
been computed in the previous iteration. Thus, the evaluation of memberOfAlpha(cl,X) 
terminates with two answers: memberOfAlpha(cl,eric) and memberOfAlpha(cl,david). 
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The example above shows that GEM can easily support policies including both loops 
and negation. We now show how GEM operates in presence of loops through negation. 
Consider the following policy statements complementing the global policy above: 

8. chemist(c2,X) <- memberOfAlpha(cl,X), chemist(c3,X). 

9. chemist(c3,eric). 

Clause 8 states that all the members of project Alpha at cl that work as chemists at 
the other partner company c3 are also chemists at c2. Note that clause 8 is "inconsistent" 
with clause 1. In fact, clause 1 defines as members of project Alpha principals that are not 
chemists at company c2; at the same time, clause 8 states that chemists at c2 are members 
of project AZ/j/jfl at cl. For this reason, whencl ascertains that goals memherOfAlpha(cl,eric) 
and chemist(c2,eric) are in a loop, it raises an error and the computation flounders. In fact, 
in the example computation above, the evaluation of chemist(c2,eric) by c2 would lead to 
a contradiction: if Eric were not a chemist at c2, he would be a member of project Alpha; 
however, if Eric were a member of project Alpha, he would be a chemist at c2. 



7 Related Work 

Research on goal evaluation has been carried out both in the field of logic programming and 
trust management. In this section we compare our work with existing frameworks focusing 
on the information disclosed during the evaluation process, based on the classification crite- 
ria defined in Section ISTI Additionally, we indicate whether the analyzed systems employ 
a centralized or distributed goal evaluation strategy and discuss the termination detection 
mechanism they adopt. Within termination detection, we distinguish between termination 
of the whole computation initiated by a particular request and termination of the single 
goals involved in the computation (i.e., detecting when a goal is completely evaluated). 
Table [3] summarizes the results of this analysis. In the table, LP denotes the algorithms 
proposed in the logic programming domain, while TM denotes trust management systems. 

SLG resolution dChen and Warren I996I I, TP-resolution jShen et al. 200Il l. DRA (|Guo and Gupta 2001 



OPTYap jRocha et al. 2005l l. and the work by Hulin d 19891 1 are centralized tabling systems 
in which the complete program (i.e., the global policy) is available during the evaluation. 
Therefore, these five systems are classified as El -13 according to the classification criteria 
defined in Section lTTl that is, they do not preserve the confidentiality of neither extensional 
nor intensional policies. SLG identifies loops by observing goal dependencies in the "call 
stack" of the program; termination is detected when no more operations can be applied to 
the goals in the stack. SLG resolution is employed in a number of Prolog systems such as, 
for instance, XSB (ISwift and Warren 2012b . The evaluation strategy employed by GEM is 
similar to the XSB scheduling strategy called local evaluation, which completely evaluates 
a sec before returning the answers of the leader to a goal outside the SCC. Similarly to 
SLD resolution ( IKowalski l l. in TP-resolution and DRA a goal is evaluated by building a 
single derivation tree for the goal. Loops are detected when a subgoal appears more than 
once in a branch of the tree, and the evaluation of a goal terminates when there are no 
more nodes in the derivation tree to be evaluated. OPTYap and Hulin propose a parallel 
tabled execution strategy to improve the efficiency of goal evaluation. OPTYap resorts to 
centralized data structures to identify loops and detect termination. In (IHulin I989l l. each 
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centralized 


centralized 


centralized 


E1-I3 




DRA (Guo and Gupta 200111 


centralized 


centralized 


centralized 


E1-I3 


LP 


OPTYap (Rocha et al. 20051 


centralized 


centralized 


centralized 


E1-I3 




Hulin(1989) 


centralized 


centralized 


centralized 


E1-I3 




Damasio (12000k 


distributed 


distributed 


distributed 


El -12 




Hu (11997) 


distributed 


distributed 


distributed 


El -12 




RT(Li etal. 2003 ) 


centralized 


centralized 


centralized 


E1-I3 




Tulip (Czenko and Etalle 2007) 


centralized 


centralized 


centralized 


E1-I3 




SecPAL iBecker et al. 2010il 


centralized 


centralized 


centralized 


E1-I3 




SD3 d Jim and Suciu 200 U 


distributed 


N/A 


N/A 


E1-I3 


TM 


Becker et al. (12009b 


distributed 


N/A 


N/A 


E1-I3 


Cassandra (Becker 2005 ) 


distributed 


no 


no 


El -10 




PeerTrust dAlves et al. 20061 


distributed 


distributed 


no 


El-Il 




distributed 


distributed 


distributed 


El -12 




MTN ([Zhang and Winslett 20081) 


distributed 


distributed 


no 


El-Il 




GEM 


distributed 


distributed 


distributed 


El-Il 



Table 3. Comparison Between Goal Evaluation Algorithms 



process communicates its termination to a global variable, whose access is limited to one 
process at a time by means of a deadlock mechanism. 

Distributed goal evaluation frameworks are presented in dHu 19971 ) and (IDamasio 20001 ). 
To detect termination, the work by Hu ( 119971 ) assumes the presence of global data struc- 
tures and requires goal dependencies to be propagated among the different principals. In 
(IDamasio 20001 ). termination detection resorts to a static dependency graph known to all 
principals and determined at compile time. Consequently, the confidentiality of (part of) 
the intensional policies is not preserved, and both algorithms are classified as El -12. 

In trust management, distributed goal evaluation is a main issue since policies are dis- 
tributed among principals. The trust management frameworks RT dLi et al. 20031 ) and Tulip 
jCzenko and Etalle 20071 ) rely on a centralized goal evaluation strategy, where all the clauses 
necessary for the evaluation of a goal are collected in a single location. Similarly, SecPAL 
(IBecker et al. 201 Ob assumes all the clauses in a global policy to be available to the prin- 
cipal responsible for the evaluation of a goal. In SD3 ( IJim and Suciu 200T1 ). when queried 
for a goal, a principal returns to the requester the clauses defining the goal, with the locally 
defined (body) atoms already evaluated. Becker et al. ( 120091 ) present an algorithm in which 
the body atoms of the clauses defining a goal are sent in turn to the principals defining 
them; each principal evaluates the atom(s) defined in her policy and sends its answers and 
the remaining atoms to the next principal, until the evaluation fails or all atoms are evalu- 
ated. As a result, policy confidentiality is not preserved by any of these algorithms, which 
are thus classified as E1-I3. Furthermore, neither Jim and Suciu ( 120011 ) nor Becker et al. 
(120091 ) discuss how termination is detected. Cassandra ( IBecker 20051 ) employs a distributed 
evaluation strategy in which no information about intensional poUcies is disclosed. How- 
ever, it does not detect neither the complete evaluation of single goals, nor the termination 
of the whole computation. 

PeerTrust dAlves et al. 20061 ) and MTN ([Zhang and Winslett 2008|) detect termination of 
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the computation started by a particular request in a fully distributed way; this is achieved 
by "observing" when no more messages are exchanged among principals and all goals are 
quiescent. In jAlves et al. 20061 1. the authors present two solutions: the first, based on the 
work in (IDamasio 20001 1. is also able to detect the completion of single goals, but requires 
the dependency graph of the global policy to be known to all principals beforehand. The 
second solution, which is also adopted in (Zhang and Winslett 2008 1, detects termination 
of the computation without disclosing information about intensional policies. However, 
since all request and response messages are tagged with the identifier of the initial request, 
some information about goal dependencies can be inferred (hence the El-Il classification); 
more precisely, a principal can learn whether a given goal depends on a goal defined in her 
policy. In addition, neither PeerTrust nor MTN features a loop identification mechanism. 
Consequently, they are not able to detect termination of individual goals, which is required 
to free the resources used during the computation and to allow the use of negation. Fur- 
thermore, when using negation, the detection of loops through negation allows to preserve 
the soundness and completeness of the computation with respect to the standard semantics 
for logic programs. We enable the identification of loops and the detection of goal termina- 
tion at the cost of possibly revealing more information about goal dependencies. In fact, in 
GEM all the principals involved in a loop are notified about the loop: on the one hand, this 
enables the principal(s) handling negated goals to terminate the computation with flounder- 
ing. On the other hand, this implies that GEM discloses information about the presence of 
mutual dependencies among goals to more principals than PeerTrust and MTN. In the ex- 
ample in Section l4~2l for instance, with PeerTrust and MTN the research institute ri would 
not receive any loop notification from company c2; therefore, ri would not learn that there 
exists a mutual dependency between memberOfAlpha(ri,X) and memberOfAlpha(c2,X). 

Besides the protection of intensional policies, preserving the confidentiality of exten- 
sional policies is also an important requirement of trust management systems, as the an- 
swers of a goal might contain sensitive information (e.g., the list of patients of a mental 
hospital). Even though none of the existing goal evaluation algorithms satisfies this require- 
ment (see Table|3]l, GEM can be easily adapted to protect the confidentiality of extensional 
policies. In particular, by enabling the distributed evaluation of policies, GEM allows prin- 
cipals to discriminate between goals that may be accessed by other principals and goals 
that may only be used for internal computations, because of their sensitivity. This distinc- 
tion is not possible when using an algorithm that relies on a centralized evaluation strategy. 
A finer-grained protection of extensional policies can be achieved by integrating GEM 
with trust negotiation algorithms ( Winsborough et al. 2000 IWinslett 20031 1. Trust negoti- 
ation algorithms protect the disclosure of extensional policies (i.e., possibly sensitive cre- 
dentials) by means of disclosure policies that specify which credentials a requester must 
provide to get access to the requested credentials. Some trust negotiation algorithms deal 
also with the protection of disclosure policies (e.g., (ISeamons et al. 200"TT l); however, they 
assume that all the credentials of the principals in a trust management system have been 
already derived when a transaction takes place (Winsborough and Li 2002 1. GEM, on the 
other hand, provides a way of deriving those credentials. Thus, GEM and trust negotiation 
algorithms can be combined in such a way that a GEM request is evaluated only if the 
requester satisfies the disclosure policy of that goal, i.e., if she is trustworthy enough to 
see the answers to the request. The resulting integrated algorithm enables distributed goal 
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evaluation while preserving the confidentiality of both intensional and extensional poli- 
cies. A similar approach is presented in jKoshutanski and Massacci 2008llLee et al. 2009I ). 
However, in (IKoshutanski and Massacci 2008l l the authors do not discuss how to deal with 
recursive policy statements, while the algorithm presented in (ILee et al. 20091 1 raises an er- 
ror in the case that cyclic dependencies are detected, and for this reason is not complete. 
MTN (Zhang and Winslett 2008 1 also applies trust negotiation strategies to distributed goal 
evaluation, but as discussed in Section [7] this algorithm is not able to detect termination 
of individual goals within a computation. In jMinami et al. 20lTl l. the authors present a 
framework to analyze and compare distributed goal evaluation algorithms based on the 
information about extensional policies that they disclose during a computation. 

To conclude, we point out that contrarily to other works on goal evaluation (e.g., jLee et al. 20101 1'). 
the distributed evaluation strategy of GEM does not allow to build the complete "proof" 
of a goal. Building such a proof is in fact similar to constructing the derivation tree of a 
goal. Even though cryptographic techniques can be employed to prevent the disclosure of 
the facts used in the derivation process JLee et al. 2009l l. the construction of such a proof 
cannot be obtained without disclosing the intensional policies of the principals involved in 
the evaluation, which is what GEM aims to avoid. We argue that the approach followed by 
GEM is consistent with the concept of trust management. In trust management, in fact, if 
the policy of a principal a refers to the policy statements of a principal 6, then a trusts b for 
the definition and evaluation of those statements. When the proof of a goal is required, the 
confidentiality requirement should be put aside in favor of a goal evaluation strategy that 
allows the construction of such a proof (e.g., RT jLi et al. 2003l l). 



8 Conclusions 

In this paper we have presented GEM, a distributed goal evaluation algorithm for trust 
management systems. Differently from many of the existing algorithms, GEM detects the 
termination of a computation in a completely distributed way without disclosing inten- 
sional policies, thereby preserving their confidentiality. In addition, GEM is able to detect 
when the single goals within a computation are fully evaluated, by enabling the identifi- 
cation of strongly connected components. Even though this may lead to the disclosure of 
some additional information about goal dependencies, it also enables the use of negation 
(as failure) in policies. In Section l4~2l we show that the information disclosed by GEM is 
not sufficient to infer the intensional policy of a principal; thus, we believe that the benefits 
of our solution overcome the drawbacks. GEM always terminates and is sound and com- 
plete with respect to the standard semantics for logic programs. As future work, we plan to 
extend GEM to support constraint rules ( ILi and Mitchell 20031 ) and subsumptive tabling. 

Although efficiency is not a primary objective of this paper, GEM can contribute to keep 
network traffic low. In fact, in most distributed goal evaluation systems (e.g., jAlves et al. 20061 )) 
answers are sent as soon as they are computed. On the contrary, GEM delays the commu- 
nication of the answers of a goal until all possible answers have been computed, i.e., until 
all the branches of the partial derivation tree of the goal have been inspected. This strategy 
may delay the identification of the answers of ground goals. However, it simplifies the ter- 
mination detection mechanism and we believe reduces the number of messages exchanged 
by principals during a computation. The experiments presented in Section |5] suggest that 
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since the computation time is dominated by network communication, a reduction in the 
number of messages exchanged between principals leads to a consistently lower computa- 
tion time. In addition, since the answers of a goal can be reused for future computations, 
the proposed solution may reduce the computation time of later evaluations. 

Based on the results of the experiments presented in Section |5] we can conclude that 
GEM performs well both in terms of computation time and memory occupation even for 
very large global policies. To confirm this conviction, we have employed GEM in some 
prototype of real-world distributed systems in the maritime safety and security jTrivellato et al. 201 II) 
and employability jBohm et al. 2010b domains. In addition, we are currently designing an 
advanced version of GEM that implements an "early loop detection" strategy to avoid the 
reevaluation of side requests. Finally, since the policy language proposed in this paper can 
be used to represent the semantics of several existing trust management languages (e.g., 
RT (ILi et al. 2003b and PeerTrust (lAlves et al. 2006b ). we point out that GEM can be used 
to evaluate goals over policies expressed in any of those languages. 

Acknoledgements. This work has been carried out as part of the POSEIDON project un- 
der the responsibility of the Embedded Systems Institute (ESI). This project is partially 
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Appendix A Proofs 

As mentioned in Section 3.3, we assume that given a request or response message AI sent 
by a principal a to a principal b, one and only one instance of message M is received by b. 
In other words, we assume no message duplication, and that messages are always received. 
We introduce one last definition. 

Definition 11 

Let S be the set of tables resulting from running GEM on a goal G w.r.t. P = Pi U 
. . . U P„. Let Gi be a goal whose table is in S. Let 6' be a solution of Gi using clause 
H ^ Pi, ... , P„. Then, by construction 39o, . . . ,6n s.t. Oq = mgu{Gi, H) and dj is a 
solution of Bj9o ■ • ■ 9j-i (with j G {1, . . . , n}). The ranking of 9 is defined inductively as 
follows: 

• rank{9) = 1 if n = (i.e., the clause is a fact), 

• rank{9) = 1 + max{rank{9i), . . . ,rank{9n)) otherwise, where rank{9j) is the 
ranking of solution 9j . □ 

We can now prove the soundness result of GEM. 

Proof of Theorem 1. We proceed by contradiction and assume that there exists at least a 
"wrong" solution 9i^j in SoU, i.e., a solution s.t. there is no corresponding SLD derivation 
of P U [Gi] with c.a.s. a where Gi9i j is a renaming of Gicr (hypothesis). 

Let us choose 9ij to be a "wrong" solution with minimal ranking (*). Let Gi = 
Ai. Since 9ij is a solution of Gi, there exists an evaluation tree of Gi in S created by 
Create Table (lines 2-7) with root {id,Ai ^ Ai,new), a subnode with clause c = 
H -s— Pi, ... , P„ and substitutions 9o, . . . ,9n s.t. 6*0 — mgu{Ai, H), and for each I G 
{1, . . . , n} there exists: 

• A node in the evaluation tree of Gi with selected atom Bi9q ■ ■ ■ 6'/_i (ACTIVATE 
Node, lines 8, 18-19). 

• An evaluation tree of <— Bi9a ■ ■ ■ 6'/_i created by CREATE Table (fines 2-7) at the 
location of Bi9o ■ ■ ■ 9i-i. 
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• A solution 6i of ^ BiOq ■■■ 0i^i; the answer Bi6q ■ ■ ■ 0i is sent to the requester of ^ 
Bi9o ■ ■ ■ Oi^i by Generate Response (lines 12-14 or 20-23) if ^ Bi9o ■ ■ ■ Oi-i 
is involved in a loop, or by TERMINATE (lines 3-5) otherwise. 

• A node with clause (H <— -B/+i , . . . , Bn)9o ■ ■ - Oi added to the evaluation tree of Gi 
by Process Response (lines 20-23). 

Then, O.i j = 6q ■ ■ -6^. If the body of c is empty, then there is a trivial 1-step SLD 
derivation of P U [Gi] with c.a.s. ai (namely the mgu of Gi and c), therefore contra- 
dicting the hypothesis. So, let us now assume that n > 0; by construction, for each 
I £ {!,..., n}, rankifii) < rank{9ij). So, by the minimality argument (*), for each 
I € {1, . . . ,n} there exists an SLD derivation of P U {■(— BiOq ■ ■ ■ with c.a.s. ai 

s.t. Biao ■ ■ ■ ai-iai = BiOq ■ ■ ■ 6i-i9i. But then, by standard logic programming results 
(given the presence of clause c), there exists a successful SLD derivation of P U {Gi} with 
c.a.s. tr s.t. Gi(7 = Gidi j, contradicting the hypothesis. □ 

Since GEM employs a "wait" mechanism to determine when the answers of a goal 
should be sent to the requester, both the completeness and termination properties of the 
algorithm depend on the correctness of this mechanism. Therefore, before demonstrating 
that GEM is complete and always terminates, we prove that the "wait" mechanism is cor- 
rectly implemented, i.e., that the answers of a goal are eventually sent to the requester. This 
is particularly challenging in the presence of loops. 

In the implementation of GEM proposed in Section 3.3, the "wait" mechanism for goals 
involved in a loop consists of loop counters: at each iteration of a loop id, the answers of 
a goal G are only sent when the counter of loop id in set ActiveGoals is (procedure 
Process Response, Hne 24). Since the counter is set to the number k of subgoals of G 
which are involved in loop id (GENERATE RESPONSE, lines 7 and 19), at each iteration 
of loop id the principal evaluating G should thus receive k response messages. In order to 
prove this, we first show that GEM correctly keeps track of the loops in which the subgoals 
of G are involved. 

Proposition 1 

Let Gi, . . . , Gm be the goals involved in a loop idi. Let Gi, Gj g {Gi, . . . , Gm} be two 
goals s.t. Gj is a subgoal of Gi. Then, the node in the evaluation tree of Gi with selected 
atom Gj has status loop(ID), where idi E ID. 

Proof of Proposition 1. Let Gi be the coordinator of loop idi. Let Gi, . . . , G/c be a sub- 
set of Gi, ... , Gm S.t. for each i G {2, . . . , fc} goal Gi is a subgoal of Gi_i, and Gi 
is a subgoal of Gfc. The node in the evaluation tree of Gi, . . . , Gfc with selected atom 
G2, . . . , Gfc, Gi respectively has status loop(ID), where idi G ID, because of the follow- 
ing observations: 

• The identifiers id2, . ■ . , idk of the requests for goals Gi, . . . , Gfc and the identifier 
idk+i of the request for goal Gi are constructed by procedures CREATE Table 
(lines 5-6) and PROCESS Response (lines 21-22) in such a way that idj iz idi, for 
each j e {2, . . . , fc + 1}, and thus the lower request idk+i for Gi can be identified. 



GEM: a Distributed Goal Evaluation Algorithm 



43 



• Upon receiving the lower request idk+i, the principal evaluating Gi returns a re- 
sponse {idk+i,Ansk+i, Sk+i,{idi}) to the principal evaluating Gk (procedure PRO- 
CESS Request, lines 5-7). 

• The status of the node in the evaluation tree of Gk with selected atom Gi is set to 
loop{{idi}) (Process Response, lines 12-13). 

• A counter for loop idi is added to set ActiveGoals in the table of goal Gk (PROCESS 
Response, line 14). 

• For each i G {2, . . . , fc}, the principal evaluating goal Gi sends to the principal 
evaluating goal Gi-i a response of the form {idi,Ansi, Si, ID), where ID is the 
set of all loops in ActiveGoals whose identifier is higher than idi (GENERATE 
Response, lines 18, 21, and 23), and thus idi e ID- 

• The status of the node in the evaluation tree of goal Gi-i with selected atom G; is 
set to loop{ID), where idi e ID (PROCESS RESPONSE, lines 12-13). □ 

Corollary 1 

Let G be a goal involved in a loop id. Let k be the number of nodes in the evaluation tree 
of G with status loop{ID) s.t. id E ID. When a response is sent to the requester of the 
higher request for G (or lower request, if G is the loop coordinator), the counter of loop id 
in set ActiveGoals in the table of G is set to k. 

At each loop iteration, the counters of the loops in which a goal G is involved are set to 
the number of subgoals of G involved in those loops by procedure GENERATE RESPONSE, 
Unes 7 and 19. Hence, we now need to show that at each iteration of a loop id the number 
of response messages with status loop (id) received by the principal evaluating G is equal 
to the number of subgoals of G involved in loop id, i.e., that counters correctly keep track 
of the number of response messages received by the principal evaluating G at each iteration 
of loop id. 

Informally, the correctness of counters stems from the fact that at each loop iteration 
step for a goal G there is only one choice of loop identifier to include in the response to the 
requester of a higher request for G. This is because of the following considerations: 

1 . Let G be a goal involved in one or more loops. In the loop processing phase, the loop 
identifier included by the principal evaluating G in the response sent to the requester 
of a higher request for G is taken from the status of the root node of the evaluation 
tree of G (procedure GENERATE RESPONSE, lines 20-21). 

2. After a response for G is sent by GENERATE RESPONSE (fines 20-23), the status of 
the root node of the evaluation tree of G is set to active (line 24). 

3. If G is a non-coordinator goal, then there can be at most one loop identifier per 
time in the status of the root node of its evaluation tree. Therefore, when sending 
a response for G, procedure GENERATE RESPONSE has only one choice of loop 
identifier to include in the response status. The reason why a non-coordinator goal 
can have at most one loop identifier in the status of the root of its evaluation tree is 
the following. The only point where the status of the root node of a non-coordinator 
goal G is modified to take into account the loop being processed is on line 18 of 
procedure PROCESS RESPONSE, and the check on line 17 updates the status only in 
case it is currently set to active. We point out that when the response for a subgoal of 
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G is processed by PROCESS RESPONSE the status of the root of the evaluation tree 
of G is always active, due to point (2) above and the fact that GEM only processes 
one goal at a time (which is due to condition on line 24 of PROCESS Response), 
and thus no response will be received by the principal evaluating G in the context of 
a loop unless a response for G was previously sent. 
4. if G is the coordinator of a loop idi, then there can be at most two loop identifiers per 
time in the status of the root node of its evaluation tree: one for loop idi, and at most 
one for a higher loop idh. Remember that as loop identifiers we use the identifier of 
the higher request for the coordinator; hence, in this case idi is the identifier of the 
higher request for G. Given the condition on line 20 of GENERATE RESPONSE, only 
idh can be included in the status of a response for G sent to the requester of a higher 
request. In fact, idh (denoted id4^ in the procedure) is the only identifier in the status 
of the root node of the evaluation tree of G that is higher than idi (denoted idi in 
the procedure), i.e., higher than the identifier of the higher request for G. Therefore, 
when sending a response for G, GENERATE RESPONSE has only one choice of loop 
identifier to include in the response status, namely idh- 

Technically, a coordinator can have at most two loop identifiers in the status of 
the root node of its evaluation tree because of the following. Similarly to non- 
coordinators, due to condition on line 17 of PROCESS RESPONSE only one loop 
identifier can be added to the root's status on line 18 of PROCESS RESPONSE. This 
occurs when G receives a response from one of its subgoals in the context of a higher 
loop idh ■ A second loop identifier (the identifier of loop idi) can be added to the root 
status on lines 8-9 of GENERATE RESPONSE if the response received by the princi- 
pal evaluating G in the context of loop idh leads to new answers of G, which need 
to be sent to the goals involved in loop idi. No more than two loops at a time will 
be processed by the principal evaluating G (i.e., idi and at most one higher loop 
idh) because of the following reasons. Upon receiving a response in the context of a 
higher loop idh'- 

• a response for G in the context of loop idh will not be sent to a higher goal 
until a fixpoint for the loop idi of which G is the coordinator is reached, 
during which time the status of the root node of the evaluation tree of G is 
loop {{idh, idi}), and 

• due to the condition on line 24 of PROCESS RESPONSE no responses for 
higher goals can be received by the principal evaluating G until a response 
for G in the context of loop idh is sent upwards. In fact, the counter of loop 
idh in the table of higher goals cannot be 0, because no response for G in the 
context of loop idh was sent upwards yet. When a response for G is sent up- 
wards, the status of the root node of its evaluation tree becomes active again 
(see point (2)). 

Formally, the correctness of counters is demonstrated by the following Proposition. 
Proposition 2 

Let G be a goal and Gi , . . . , G^ be the subgoals of G s.t. G,Gi, . . . ,Gk are involved in 
a loop idi. At each iteration of loop idi, the principal evaluating G receives k response 
messages, one for each subgoal Gi G {Gi, . . . , Gfc}. 
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Proof of Proposition 2. Let G, Gi, . . . , Gk, • • • , Gm be all the goals involved in loop idi, 
where m > k. Let id, idi, . . . , id„i be the identifiers of the requests for goals G, Gi , . . . , G, 
respectively. The proof is by induction on the number i of goals Gj G {Gi, . . . , Gm} s.t. 
idj C id, that is, the number of goals whose request identifier is lower than the identifier 
id of the request for G. 

Base case: £ = 1. Then, also k — 1. Let Gj G {Gi, . . . ,Gm} be the only goal s.t. 
idj □ It is straightforward to see that goal Gj is (a variant of) the coordinator of loop 
idi, and idj denotes the lower request for Gj . When there are no more nodes with status 
new in the evaluation tree of Gj, i.e., when all the branches of the evaluation tree of Gj 
have been evaluated, procedure GENERATE RESPONSE is invoked by ACTIVATE NODE 
(fines 2-3). By procedure GENERATE RESPONSE (lines 12-14), at each loop iteration 
one and only one response to the request for the coordinator Gj is sent by GEM to the 
principal evaluating G. Thus, at each iteration of loop idi the principal evaluating G 
receives fc = 1 response messages. Q.e.d. 

Inductive case: Now, assume that G has £ such goals Gj G {Gi, . . . , Gm} s.t. idj c 
id, where £ > 1. In this case, each subgoal G; G {Gi, . . . , Gk} of G is either the 
coordinator of loop idi or a goal with at most £ — k subgoals Gp G {Gi , . . . , Gm} s.t. 
idp \Z idi. If Gi is the coordinator of loop idi, by the same reasoning done in the base 
case, one and only one response to the request for Gi is sent by GEM to the principal 
evaluating G at each loop iteration. 

On the other hand, if Gi is not the loop coordinator, there exist at most £ ~ k goals 
Gp G {Gi, . . . , Gm} s.t. idp IZ idi. Let t be the number of subgoals of Gi involved in 
loop idi. Since £~k < £ — 1, by the inductive hypothesis (*) the principal evaluating Gi 
receives t response messages at each iteration of loop idi. By Corollary 1, at each loop 
iteration the counter of loop idi in the table of goal Gi is set to t, and is decreased by 
1 every time a response to the requests for its subgoals involved in the loop is received 
(procedure PROCESS RESPONSE, lines 15-16). Therefore, after t response messages, 
the counter of loop idi in the table of G^ is 0, and procedure PROCESS RESPONSE 
(lines 24-25) resumes the evaluation of goal Gi. When there are no more nodes with 
status new in the evaluation tree of Gi, procedure ACTIVATE NODE (lines 2-3) invokes 
Generate Response. By procedure Generate Response (lines 20-21), one and 
only one response to the request for Gi is sent by GEM to the principal evaluating G at 
each iteration of loop idi. Therefore, at each iteration of loop idi the principal evaluating 
goal G receives k response messages. □ 

Finally, we show that procedure TERMINATE is eventually invoked for any goal in a 
computation. 

Proposition 3 

Let Gi be a goal. Procedure TERMINATE is eventually called for Gi. 

Proof of Proposition 3. The proof is divided into two parts. First, we show that TERMINATE 
is eventually called for a goal Gi that is not involved in a loop. Then, we show that it is 
always invoked also if Gi is involved in one or more loops. 

The first part of the proof is straightforward, and is given by the fact that the number of 
answers of goal Gi is finite. This is because of the following observations; 
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1 . The global policy P is finite, and the terms in P that are not variables are constants 
defined in P; thus, the Herbrand model of P is finite. 

2. Let Pgi E P hs the policy where goal Gi is defined. The answers of Gi are com- 
puted by GEM through the clauses in Pqi applicable to Gi (procedure CREATE Ta- 
ble, lines 3-7). Each clause can be either a fact or have the form £f <— . . . , Bm, 
such that Bi, . . . , Bm are defined in a policy in P. By (1), both the number of facts 
in Pgi and the number of answers of subgoals Bi, . . . , _B„ are finite. 

Thus, the number of answers of goal Gi is finite. When all the answers of Gi have been 
computed and all the nodes in the partial tree of Gi have been evaluated, procedure ACTI- 
VATE Node (lines 2-3) invokes Generate Response, which in turn (lines 2-3) invokes 
Terminate. 

Consider now the case in which Gi is part of an SCC consisting of loops idi, . . . , idk, s.t. 
idk C . . . C idi. Let Gi, . . . , Gm be all the goals involved in loops idi, . . . , idk (where 
m > k), and goal G^ S {Gi , . . . , Gm} be the coordinator of loop idi G {idi, - ■ ■ ^ idk}. 
Because the number of answers of each goal Gi , . . . , Gm is finite, we have that: 

• At each iteration of loop idi, if new answers of the loop coordinator Gc, are derived, 
they are sent to the requesters of the lower requests for G^ , starting a new iteration 
of loop idi (procedure GENERATE RESPONSE, lines 6-14). On the contrary, if no 
answer of Ga is computed, the answers of G^ are sent to the requester of the higher 
request for G^ (Generate Response, lines 20-23). The loops higher than idi in 
the SCC are then processed. 

• At each iteration of loop idi, if new answers of the leader Gci are derived, they are 
sent to the requesters of the lower requests for Gci , starting a new iteration of loop 
idi (procedure GENERATE Response, lines 6-14). Notice that this might cause a 
fixpoint for the loops lower than idi in the SCC to be recomputed. On the contrary, 
if no answer of Gci is computed, the answers of Gci are sent to the requester of the 
higher request for Gci , and a response with status disposed is sent to the requesters 
of the lower requests for Gci (GENERATE RESPONSE, fines 15-16 and TERMINATE, 
lines 3-5). 

• For each goal Gj £ {Gi, . . . , Gm}, all the nodes in the evaluation tree of Gj are 
disposed (PROCESS RESPONSE, lines 5-8); then, procedure ACTIVATE Node is in- 
voked, which immediately invokes GENERATE RESPONSE (lines 2-3). 

• The principal evaluating goal Gj sends a response with status disposed to the re- 
quester of the higher request for Gj. If Gj is a loop coordinator, the principal eval- 
uating Gj also sends a response with status disposed to the requesters of the lower 
requests for G,j (GENERATE RESPONSE, lines 2-3 and TERMINATE, lines 3-5). 

Therefore, procedure TERMINATE is always invoked for goal Gi . □ 

Proposition [3] implies that the table of a goal involved in a computation is always dis- 
posed. In fact, the disposal of the table of a goal is carried out by procedure TERMINATE 
(lines 2, 6, and 7). Consider, for instance, the following variation of the global policy intro- 
duced in Section 3.1, where the research insitute ri refers to goal member Of Alpha{cl,X) 
instead of memberOfAlpha{c2,X): 
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memberOfAlpha(cl,X) ^ memberOfAlpha(c2,X). 
memberOfAlpha(c2,X) ^ memberOfAlpha(rz,X). 
memberOfAlpha(ri,X) <r- memberOfAlpha(cl,X). 

First of all, let us recall that the termination of the evaluation of the goals involved in a 
loop is commanded by the leader of the SCC (goal member Of Alpha{c\,X) in the exam- 
ple policy). When no new answer of the leader is computed by ci during a loop iteration, 
procedure TERMINATE is invoked (Unes 15-16 of GENERATE Response), which disposes 
the table of the goal and sends a response with status disposed both to the requesters of the 
higher and lower requests for member OfAlpha{cl,X) (lines 3-5). When ri receives the re- 
sponse, it disposes all the nodes in the evaluation tree of memberOfAlpha{ri,X) involved 
in a loop (lines 5-8 of PROCESS Response), which in this case corresponds to disposing 
all the non-root nodes. At this point, the status of the root node of the evaluation tree of 
memberOfAlpha{ri,X) is active (see point 2 of the discussion preceding Proposition |2]l. 
Therefore, the condition on Hne 24 of PROCESS RESPONSE is satisfied, and procedure AC- 
TIVATE Node is invoked for memberOfAlpha{cl,X). Since all the non-root nodes in the 
evaluation ti-ee of memberOfAlpha{cl,X) have status disposed, GENERATE Response 
is invoked (lines 2-3 of ACTIVATE Node), which in turn (lines 2-3) invokes procedure 
Terminate. Terminate disposes the table of goal memberOfAlpha(ri,X) and sends a 
response with status disposed to c2. Similarly to memberOfAlpha{ri,X), PROCESS RE- 
SPONSE disposes all the nodes in the evaluation tree of goal memberOfAlpha(c2,X), and 
a response with status disposed is sent by c2 to cl by procedure TERMINATE. Since the 
root of the evaluation tree of memberOfAlpha(cl,X) had already been disposed, in this 
case the response message is ignored by cl (line 4 of PROCESS RESPONSE). 

Next, we prove the completeness and termination results. 

Proof of Theorem 2. We proceed by contradiction, and assume that S is missing a solution 
of Gi. That is, there exists a successful SLD derivation of P U {Gi } with c.a.s. 6 and there 
is no solution a of Gi generated by the algorithm s.t. Gi6 = Gict (hypothesis). 
This implies that there exist a (maximal) set of goals Gi, . . . , Gfc in S s.t. for each i e 
{1, . . . , fc} there is a non-empty maximal set of substitutions . . . , di^mi} s.t.: 

(a) Gi is a goal in S. 

(b) 1 , . . . , Oi^rrii are correct solutions of Gi according to SLD resolution: for each 9ij 
there exists a successful SLD derivation of PU{Gi} with c.a.s. di j (up to renaming). 

(c) The algorithm does not generate the answers Gidi,i, ■ ■ ■ , Gi6i,mi (up to renaming). 

The set Gi , . . . , Gk is not empty as it contains at least Gi (the finiteness of the construction 
is demonstrated in the proof of Proposition 3). 

For each let derij be the SLD derivation of P U {Gi} with c.a.s. 9ij of minimal 
length. Let us choose integers p, q in such a way that derp,q has minimal length among the 
derivations in the set {derij}. The fact that der.p^q has minimal length implies that for any 
goal G' in 5, the following holds: if there exists an SLD derivation of P U {G'} of length 
smaller than len{derp,g) with c.a.s. 6', then the algorithm generates a solution for which 
G'd' is a renaming of G'i9' (*). 

Let c be the clause used in the first step of the derivation derp^q. If c is a fact, we im- 
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mediately have a contradiction: since Gp is a goal in S, this means that there exists an 
evaluation tree of Gp =■(— Ap created by CREATE Table (lines 2-7) with root node 
{id,Ap <— Ap,new) and a node with clause c as subnode of the root node. Therefore, 
the algorithm will compute a c.a.s. equivalent to 9p,g (ACTIVATE Node), contradicting the 
hypothesis. 

If c is a rule H ^ Bi, . . . and cto = mgu{Gp, H), then by hypothesis there 
exist SLD derivations dersi , ■ • ■ , ders^, and substitutions cti, . . . , (T„ s.t. iJtro • ■ • = 
GpOp^q, and for each i G {1, . . . , n}: 

• dersi is an SLD derivation of P U Bia^ ■ ■ ■ ai-i}. 

• The c.a.s. of ders. is tXi, and len{derBi) < len{derp^q). (**) 

Since Gp is a goal in S, there exists an evaluation tree of Gp created by CREATE Table 
(lines 2-7) with root node {id, Ap -i^ Ap, new) and a node with clause c as subnode of the 
root node. Then, it is easy to see that for each i G {1, . . . , n}: 

• There exists a node in the evaluation tree of Gp with selected atom Bia^ ■ ■ ■ di-i 
(Activate Node, lines 8, 18-19). 

• There exists an evaluation tree of <— i?icro • • ■ (Ti^i created by CREATE Table 
(lines 2-7) at the location of Bia^ ■ ■ ■ (Ji-i- 

• Since len{derBi) < len{derp^q), by (*) and (**) the algorithm computes a solution 
equivalent to (Ti of the goal <— Biao ■ ■ ■ (7i_i. 

• By Propositions 2 and 3, the answer BjCTo • • • cr,; is sent to the requester of ^ Bjao ■ ■ ■ (Ji-i 
by Generate Response (lines 12-14 or 20-23) if ^ Bicro ■ ■ ■ o-i-i is involved in 

a loop, or by TERMINATE (lines 3-5) otherwise. 

• There exists a node with clause {H . • . , Bn)ao ■ ■ ■ (Ji added to the evalua- 
tion tree of Gp by PROCESS Response (lines 20-23). 

Therefore, cri • • ■ cr„ is (equivalent to) a solution of the evaluation tree of Gp, contradicting 
(a), (b), and (c). □ 

Proof of Theorem 3. We assume that nodes (i.e., goals) in the call graph of P inherit the 
identifier (and the associated ordering) of the request for which they are created. Termina- 
tion follows from two observations: (i) the call graph of P is finite, and (ii) the number of 
response messages exchanged by the principals involved in the evaluation of G is finite. 
The call graph of P is finite (i) for the following reasons: 

1 . The set of goals over predicates in P (up to renaming) is finite. This is because terms 
that are not variables are constants in P. 

2. There is no infinite path in the call graph of P composed of nodes idi, . . . , idn s.t. 
idn C ... C idi. This is because of (1) and because the algorithm never creates a 
new node with identifier idi for a goal if a node with identifier idj already exists for 
a variant of that goal and idi □ idj. 

3. The outdegree of each node in the call graph of P is finite. This is because the 
number of atoms in the body of each clause in P is finite. 

The number of response messages is finite (ii) because: 

1 . The number of answers of each goal defined in P is finite (see the proof of Proposi- 
tion 3). 
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memberOfAlpha{cl,X) 
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projectPartner(mc,Y) 



memberOfAlpha(c2,X) 



memberOfAlpha{c3,X) 



Fig. B 1. Call Graph of the Evaluation of memberOfAlpha(cl,X) with Respect to the Ex- 
ample Global Policy 

2. The (possibly empty) set of answers of a goal are transmitted only when a table for 
the goal is first created (and a node representing the goal is added to the call graph 
of P) or new answers of its subgoals are received. 

3. For any nodes idi and id2, a set of answers that flows from id2 to id^ in response to a 
request id2 never contains answers previously communicated in response to request 
id2 (Send Response, lines 3-4). 

4. An empty set of answers may flow from id2 to idi only if id2 C idi (GENER- 
ATE Response, Hnes 20-23, and Terminate, lines 3-5), or idi identifies a lower 
request and a loop id2 has just been identified (PROCESS REQUEST, Hnes 5-7). 

5. There is no infinite path composed of nodes idn, . . . ,idi in the call graph of P 
through which the answers flow s.t. zd„ IZ . . . C idi. 

6. By Proposition 3, procedure TERMINATE is eventually invoked for any goal. □ 



In this section we show how GEM computes the answers of a goal using the procedures 
presented in Section 3.3. As an example global policy, we use a fragment of the policy 
introduced in Section 1 . In particular, we consider the following policy statements: 

1. memberOfAlpha(cl,X) projectPartner(mc,y), memberOfAlpha(y,X). 

2. projectPartner(mc,c2). 

3. projectPartner(mc,c3). 

4. memberOfAlpha(c2,X) ^ memberOfAlpha(cl,X). 

5. memberOfAlpha(c2, a/ice). 

6. memberOfAlpha(c3,6o6). 

The call graph of the global policy is shown in Figure IB II We illustrate the compu- 
tation for an initial request (hi,h,memberOfAlplia(cl,X)) from hospital h to company cl. 
Table lB ll shows the list of all procedure calls made by GEM to produce the response to the 
initial request. The first column of the table indicates the order in which the calls are made; 
the second column denotes the principal and location where each procedure is evaluated. 
GEM computes the answers of goal memberOfAlpha(cl,X) by making 53 procedure calls; 
the number of messages exchanged between different principals, however, is only 14, con- 
sisting of 5 request messages and 9 response messages (including the initial request and 
its response). Next, we present and discuss some "screenshots" showing the status of the 
computation at various stages. 
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Call 




Pi*nppHiiT'p 


1 


cl 


Proces S REQUEST((hi ,h,memberOf Alpha(cl ,X))) 


2 


cl 


Activate NODE(memberOf Alpha(c 1 ,X)) 


3 


mc 


Process REQUEST((hicli,cl,projectPartner(mc,Y))) 


4 


mc 


Activate NODE(projectPartner(mc,Y)) 


5 


mc 


Activate NODE(projectPartner(mc,Y)) 


6 


mc 


Activate NODE(projectPartner(mc,Y)) 


7 


mc 


Generate Res pons E(projectPartner(mc,Y)) 


8 


mc 


TERMINATE(projectPai-tner(mc,Y)) 


9 


mc 


Send RESPONSE((hicli,cl,projectPartner(mc,Y)),disposed,{}) 


10 


cl 


Process RESPONSE(hicli,{projectPartner(mc,c2),projectPartner(mc,c3)},disposed,{}) 


11 


cl 


Activate NODE(memberOf Alpha(c 1 ,X)) 


12 


c2 


Process REQUEST((hicl2,cl,memberOfAlpha(c2,X))) 


13 


c2 


Activate NODE(memberOfAlpha(c2,X)) 


14 


cl 


Process REQUEST((hicl2c2i,c2,memberOfAlpha(cl,X))) 


15 


cl 


Send RESPONSE((hicl2c2i,c2,memberOfAlpha(cl,X)),active,{hi}) 


16 


c2 


Process RESPONSE(hicl2c2i,{},active,{hi}) 


17 


c2 


Activate NODE(memberOfAlpha(c2,X)) 


18 


c2 


Activate NODE(memberOfAlpha(c2,X)) 


19 


c2 


Generate Res pons E(memberOfAlpha(c2,X)) 


20 


c2 


Send RESPONSE((hicl2,cl,memberOfAlpha(c2,X)),active,{hi }) 


21 


cl 


Process RESPONSE(hicl2,{memberOfAlpha(c2,aIice)},active,{hi }) 


22 


cl 


Activate NODE(memberOfAlpha(cl,X)) 


23 


c3 


Process REQUEST((hicl3,cl,memberOfAlpha(c3,X))) 


24 


c3 


Activate NODE(memberOfAlpha(c3,X)) 


25 


c3 


Activate NODE(memberOfAlpha(c3,X)) 


26 


c3 


Generate RESPONSE(memberOfAlpha(c3,X)) 


27 


c3 


TERMINATE(memberOfAlpha(c3,X)) 


28 


c3 


Send RESPONSE((hicl3,cl,memberOfAlpha(c3,X)),disposed,{}) 


29 


cl 


Process RESPONSE(hicl3,{memberOfAlpha(c3,bob)},disposed,{}) 


30 


cl 


Activate NODE(memberOf Alpha(c 1 ,X)) 


31 


cl 


Activate NODE(memberOfAlpha(cl,X)) 


32 


cl 


Activate NODE(memberOfAlpha(cl,X)) 


33 


cl 


Generate RESPONSE(memberOfAlpha(cl,X)) 


34 


cl 


Send RESPONSE((hicl2c2i,c2,memberOfAlpha(cl,X)),loop(hi),{}) 


35 


c2 


Process RESPONSE(hicl2c2i,{memberOfAlpha(cl,alice),memberOfAlpha(cl,bob)},loop(hi ),{}) 


36 


c2 


Activate NGDE(memberOfAlpha(c2,X)) 


37 


c2 


Activate NODE(memberOfAlpha(c2,X)) 


38 


c2 


Activate NODE(memberOfAlpha(c2,X)) 


39 


c2 


Generate RESPONSE(memberOfAlpha(c2,X)) 


40 


c2 


Send RESPONSE((hicl2,cl,memberOfAlpha(c2,X)),loop(hi),{hi}) 


41 


cl 


Process RESPONSE(hicl2,{memberOfAlpha(c2,bob)},loop(hi),{hi}) 


42 


cl 


Activate NGDE(memberOf Alpha(c 1 ,X)) 


43 


cl 


Activate NODE(memberOf Alpha(c 1 ,X)) 


44 


cl 


Generate Res pons E(memberOfAlpha(cl,X)) 


45 


cl 


TERMINATE(memberOf Alpha(c 1 ,X)) 


46 


cl 


Send RESPONSE((hi,h,memberOfAlpha(cl,X)),disposed,{}) 


47 


cl 


Send RESPONSE((hicl2c2i.c2,memberOfAlpha(cl,X)),disposed,{}) 


48 


c2 


Process RESPONSE(hicl2c2i,{},disposed,{}) 


49 


c2 


Activate NODE(memberOfAlpha(c2,X)) 


50 


c2 


Generate Res pons E(memberOfAlpha(c2,X)) 


51 


c2 


TERMINATE(memberOfAlpha(c2,X)) 


52 


c2 


Send RESPONSE((hicl2,cl,memberOfAlpha(c2,X)),disposed,{}) 


53 


cl 


Process RESPONSE(hicl2,{}.disposed.{}) 



Table B 1 . Procedure Call Stack For the Example Global Policy 

When principal cl receives the request for goal memberOfAlpha(cl,X) from h, it calls 
procedure Process Request (Algorithm 1 in Section 3.3) that initializes the table of 
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Principal cl 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



(hi ,h,^memberOf Alpha(c 1 ,X)) 

{} 

{} 

{} 

(hi ,memberOf Alpha(c 1 ,X)-<— memberOf Alpha(c 1 ,X),new) 

(hicli,memberOfAlpha(cl,X)-i— projectPartner(mc,Y), memberOf Alpha(Y,X),new) 



Table B 2. Status of the Computation After Procedure Call 1 in Table IB l1 



Principal cl 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



(hi ,h,^memberOf Alpha(c 1 ,X)) 

{} 

{} 

{} 

(hi ,memberOf Alpha(c 1 ,X)-;— memberOf Alpha(c 1 ,X),active) 

(hi cli, memberOf Alpha(cl,X)<— projectPartner(mc,Y), memberOf Alpha(Y,X), active) 



Principal mc 



HR 

LR 

ActiveGoals 

AnsSet 

Tree 



(hi cli ,c 1 ,-^-projectPartner(mc, Y)) 

{} 
{} 

{(projectPartner(mc,c2),{}),(projectPartner(mc,c3),{})} 
(hicli,projectPartner(mc,Y)-;— projectPartner(mc,Y),new) 
(hi cl 1 mc 1 ,projectPartner(mc,c2),answer) 
(hi cli mc2 ,projectPartner(mc,c3),answer) 



Table B 3. Status of the Computation After Procedure Call 7 in Table IB l1 



the goal. Table IB 2l shows the table of memberOfAlpha(cl,X) resulting from the execution 
of Process Request on the initial request. The table field HR (higher request) is set 
to the initial request, and the evaluation tree of the goal. Tree, is initialized by adding to 
the root node a subnode representing the only clause in el's local policy applicable to the 
goal, i.e., clause 1. The node status is set to new, and the node identifier is obtained by 
concatenating the request identifier hi with string cli. To keep the representation more 
compact, in Table IB 2l and in the other tables presented in this section the evaluation tree of 
a goal is represented as a list of nodes rather than as the structure defined in Section 3.3. 

In order to compute the list of project members, cl needs to first retrieve from mc the 
list of partner companies in the project, and then for each of these companies the list of 
its project members. Table IB 31 shows the status of the computation after goal project- 
Partner(mc,Y) has been completely evaluated by mc (procedure calls 2 to 7 in Table IB iT) . 
i.e., after the set of project partners has been computed. The request for goal projectPart- 
ner(mc,Y) from cl to mc is generated by the activation of node /iicli in el's table (pro- 
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Principal cl 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



(hi ,h,<— memberOf Alpha(c 1 ,X)) 

{(hicl2c2i,c2,<-memberOfAlpha(cl,X))} 

{} 

{} 

(hi ,memberOf Alpha(c 1 ,X)<— memberOf Alpha(c 1 ,X),active) 

(hicli,memberOfAlpha(cl,X)^ projectPartner(mc,Y), memberOf Alpha(Y,X),disposed) 
(hi cl2, memberOf Alpha(cl,X)^ memberOf Alpha(c2,X),active) 
(hi els, memberOf Alpha(cl,X)<— memberOf Alpha(c3,X),new) 



Principal mc 



HR 

LR 

ActiveGoals 

AnsSet 

Tree 



null 

{} 
{} 

{(projectPartner(mc,c2),{hicli}),(projectPartner(mc,c3),{hicli})} 
(hicli,projectPartner(mc,Y)-s— projectPartner(mc,Y),disposed) 
(hi c 1 1 mc 1 ,projectPartner(mc,c2) ,answer) 
(hi c 1 1 mc2 ,projectPartner(mc,c3) .answer) 



Principal c2 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



(hi cl2 ,c 1 memberOf Alpha(c2,X)) 

{} 

{} 

{} 

(hi cl2, memberOf Alpha(c2,X)-<— memberOf Alpha(c2,X),active) 
(hi cl2c2i, memberOf Alpha(c2,X)-<— memberOf Alpha(cl,X),active) 
(hi cl2c22, memberOf Alpha(c2,alice),new) 



Table B 4. Status of the Computation After Procedure Call 15 in Table IB II 



cedure call 2, ACTIVATE NODE), which results in a change of status from new to active 
of both the root node and the node itself. Similarly to cl, when mc receives the request 
it creates the table of the goal (call 3 in Table IbTI ). setting HR to the higher request and 
initiaUzing Tree with clauses 2 and 3 of the global policy presented above. Two calls 
to procedure ACTIVATE Node (calls 4 and 5) lead to the identification of two answers 
of the goal, namely projectPartner(mc,c2) and pmjectPartner(mc,c3), which are added to 
AnsSet with an empty list of request identifiers. At the next call to ACTIVATE NODE 
(call 6), the evaluation tree of goal projectPartner(mc,Y) has no more nodes to activate 
(i.e., all the branches of the evaluation tree have been inspected) and procedure GENER- 
ATE Response is invoked (call 7). Since the goal is not involved in any loop, its evaluation 
is completed and procedure TERMINATE is executed next (line 3 of Algorithm 6 in Sec- 
tion 3.3). 

As a result of the execution of procedure TERMINATE, the root node of the evalua- 
tion tree of goal projectPartner(mc,Y) is disposed and the answers identified are sent to 
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cl through procedure Send Response (procedure call 9, results shown in Table lB4b . 
The response message received by cl is processed by procedure PROCESS RESPONSE; the 
message contains the two answers {projectPartner(mc,c2) and projectPartner(mc,c2>)) and 
an empty set of loop identifiers, and has status disposed, indicating that no more answers of 
goal projectPartner(mc, Y) will be received. The evaluation tree of goal memberOfAlpha(c\,X) 
is updated by adding two subnodes to node /jicli, one for each project partner (see el's 
table in Table |B4]|. 

The activation of node /11CI2 by cl leads to the request for goal memberOfAlpha(c2,X) 
to c2. Accordingly, c2 creates a table for the goal; the evaluation tree of the goal consists of 
three nodes: the root node and two subnodes, representing clauses 4 and 5 of the global pol- 
icy, with identifiers /2icl2c2i and /11CI2C22 respectively. The activation of node hicl2c2i 
by c2, in turn, leads to a request for goal memberOfAlpha(cl,X) to cl, forming a loop. The 
loop is identified by cl in procedure PROCESS REQUEST (call 14 in Table IB II) : in fact, the 
identifier of the higher request for memberOfAlpha(cl,X) (hi) is a prefix of the identifier 
of c2's request (/!icl2c2i). Therefore, the lower request is added by cl to set LR, and a 
response is sent from cl to c2 with a notification of loop hi (call 15). 

The loop notification sent from cl to c2 starts the loop processing phase, which in- 
volves procedure calls from 16 to 34 in Table IB II The results of the loop processing 
phase are shown in Table IB 51 Upon receiving the loop notification, c2 sets the status of 
the node whose evaluation formed the loop to loop({hi}) and "freezes" its evaluation; 
then, it proceeds with the evaluation of the other nodes of the evaluation tree. The ac- 
tivation of node /iicl2c22 (procedure call 17), in particular, leads to the first answer of 
the goal, i.e., memberOfAlpha(c2,alice). Since at this point there are no more nodes to 
be activated, the computed answer can be sent to cl with a notification about the loop. 
Before sending the answer, c2 sets the counter in ActiveGoals to 1 (procedure GENER- 
ATE Response, call 19) and adds the identifier of HR to the set of recipients of answer 
memberOfAlpha(c2,alice) in AnsSet (procedure Send Response, call 20). 

The loop is now processed at cl. After adding a subnode to the evaluation tree of 
goal memberOfAlpha(cl,X) for the answer received from c2, cl freezes node hicl2 and 
starts the evaluation of node /iicla (procedure call 22). This results in a request from 
cl to c3 for the evaluation of goal memberOfAlpha(c3,X). The only clause applicable 
to memberOfAlpha(c3,X) (clause 6 of the global policy) is a fact; therefore, the goal is 
completely evaluated after one call to procedure ACTIVATE NODE (call 24). The an- 
swer of the goal, memberOfAlpha(c3,bob), is returned to cl (procedure call 28). Since 
the status of the response message is disposed, cl disposes node /iicla and adds subn- 
ode hicl^ to it reflecting the answer received from c3 (procedure PROCESS RESPONSE, 
call 29). The next two executions of procedure ACTIVATE NODE at cl lead to the identi- 
fication of two answers of goal memberOfAlpha(cl,X), namely memberOfAlpha(cl,alice) 
and memberOfAlpha(cl,bob). Before returning these answers to the requester of HR (i.e., 
h), however, all the loops need to be fully processed. For this reason, cl sends the two an- 
swers to c2 in response to LR first; the status of the response message is loop(hi), and the 
status of the root node of the evaluation tree in el's table is changed accordingly (procedure 
calls 33 and 34 in Table IbTTi. 

Now, the second iteration of the loop processing phase starts (procedure calls 35-44). In 
this second iteration, c2 identifies a new answer of its goal, i.e., memberOfAlpha(c2,bob), 
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Principal cl 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



(hi ,h,<— memberOf Alpha(c 1 ,X)) 

{(hicl2c2i,c2,<-memberOfAlpha(cl,X))} 

{(hi,l)} 

{(memberOfAlpha(cl,alice),{hicl2c2i}),(memberOfAlpha(cl,bob),{hicl2c2i})} 
(hi,memberOfAlpha(cl,X)^ memberOfAlpha(cl,X),loop({hi })) 

(hicli,memberOfAlpha(cl,X)^ projectPartner(mc,Y), memberOfAlpha(Y,X),disposed) 
(hicl2,memberOfAlpha(cl,X)^ memberOfAlpha(c2,X),loop({hi })) 
(hicl3,memberOfAlpha(cl,X)<— memberOfAlpha(c3,X), disposed) 
(hi c I4 ,memberOf Alpha(c 1 ,aUce), answer) 
(hi CI5 .memberOf Alpha(c 1 ,bob), answer) 



Principal me 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



null 

{} 
{} 

{(projectPartner(mc,c2),{hicli}),(projectPartner(mc,c3),{hicli})} 
(hicli,projectPartner(mc,Y)-5— projectPartner(mc,Y),disposed) 
(hi cl 1 mci ,projectPartner(mc,c2) ,answer) 
(hi cl 1 mc2 ,projectPartner(mc,c3),answer) 



Principal c2 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



(hi CI2 ,c 1 , memberOf Alpha(c2,X)) 
{} 

{(hi,l)} 

{ (memberOf Alpha(c2, alice) ,{hicl2})} 

(hicl2,memberOfAlpha(c2,X)-<— memberOf Alpha(c2,X), active) 
(hicl2c2i,memberOfAlpha(c2,X)-s— memberOf Alpha(cl,X),loop({hi })) 
(hi cl2c22, memberOf Alpha(c2,alice), answer) 



Principal c3 



HR 

LR 

ActiveGoals 

AnsSet 

Tree 



null 

{} 
{} 

{(memberOfAlpha(c3,bob),{hi CI3 })} 

(hi CI3, memberOf Alpha(c3,X)^ memberOf Alpha(c3,X),disposed) 
(hi clscSi, memberOf Alpha(c3,bob), answer) 



Table B 5. Status of the Computation After Procedure Call 34 in Table IB II 



which is sent back to cl. This answer, however, does not lead to new answers at cl. Since hi 
is the only loop in the SCC (and hence memberOfAlpha(cl,X)is the leader of the SCC), and 
no new answers of memberOf Alpha(cl,X) have been computed, the loop termination phase 
can start (line 15 of Algorithm 6 in Section 3.3). In this phase, cl sends a response mes- 
sage with status disposed to both c2 (the other principal in the loop) and h (to which also 
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Principal cl 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



null 

{} 
{} 

{(memberOfAlpha(cl,alice),{hicl2c2i,hi}),(memberOfAlpha(cl,bob),{hicl2c2i,hi})} 
(hi ,memberOf Alpha(c 1 ,X)-;— memberOf Alpha(c 1 ,X),disposed) 

(hicli,memberOfAlpha(cl,X)-i— projectPartner(mc,Y), memberOf Alpha(Y,X),disposed) 

(hi cl2, memberOf Alpha(cl,X)-i— memberOf Alpha(c2,X),disposed) 

(hi els, memberOf Alpha(cl,X)4— memberOf Alpha(c3,X), disposed) 

(hi c I4 ,memberOf Alpha(c 1 ,alice), answer) 

(hi CI5 , memberOf Alpha(c 1 ,bob), answer) 

(hi cle , memberOf Alpha(c 1 ,bob), answer) 



Principal mc 



HR 

LR 

ActiveGoals 

AnsSet 

Tree 



null 

{} 

{} 

{(projectPartner(mc,c2),{hicli}),(projectPartner(mc,c3),{hicli})} 
(hicli,projectPartner(mc,Y)-5— projectPartner(mc,Y),disposed) 
(hi c 1 1 mci ,projectPartner(mc,c2) ,answer) 
(hiclimc2,projectPartner(mc,c3),answer) 



Principal c2 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



null 

{} 

{} 

{(memberOfAlpha(c2,alice), {hi CI2}), (memberOf Alpha(c2,bob), {hi CI2})} 
(hi CI2, memberOf Alpha(c2,X)4- memberOf Alpha(c2,X), disposed) 
(hi cl2c2i, memberOf Alpha(c2,X)-s— memberOf Alpha(cl,X),disposed) 
(hi cl2c22 , memberOf Alpha(c2,alice), answer) 
(hicl2c23, memberOf Alpha(c2,alice), answer) 
(hicl2c24,memberOfAlpha(c2,bob), answer) 



Principal c3 



HR 
LR 

ActiveGoals 

AnsSet 

Tree 



null 

{} 
{} 

{(memberOfAlpha(c3,bob),{hicl3})} 

(hi CI3, memberOf Alpha(c3,X)-<— memberOf Alpha(c3,X),disposed) 
(hi clscSi, memberOf Alpha(c3,bob), answer) 



Table B 6. Final Status of the Computation for the Example Global Policy 



the answers are sent). Upon receiving this message, c2 disposes all the nodes in the eval- 
uation tree of memberOf Alpha{c2,X) that are involved in some loop (procedure PROCESS 
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Fig. C 1. Call Graph of the Global Policies Used in the Experiments Set 1 



(b) Call Uraph ot the 
Global Policies 3.0 to 
3.5 



Response), and forwards the message back to cl (calls 51 and 52). cl simply ignores the 
message, as the status of the root node of the evaluation tree of memberOfAlpha(c\,X) is 
already disposed (line 4 of Algorithm 5 in Section 3.3), and the computation terminates. 
Table lB 6l shows the status of the tables of all the goals at the end of the computation. 



Appendix C Practical Evaluation 

Figure ICTI shows how the global policies defined in Appendix B and in Section 3.1 have 
been modified to evaluate the performance of GEM in response to an increase in: (1) the 
number of principals and clauses (Figure [T(a)] i, (2) the number of loops (Figure [T(c)l ), and 
(3) both the number of principals, clauses and loops (Figure |l(b)[ ) in a global policy. For 
each global policy, six variants have been created; in the figures, we use identifiers from x.O 
to X.5 (where x is either 1, 2, or 3) to denote the variants, where variant x.O represents the 
original policy. To keep the figures as simple yet informative as possible, we label the nodes 
in the graph with the identifier of the principal evaluating the goal they represent rather than 
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Fig. C 2. Time and Memory Results for Experiments Set 1 

with the goal itself, as for the purpose of the experiments the number of principals involved 
in a computation is more relevant than the goals they evaluate. 

Figures lC^ and lC3] provide a graphical overview of the main evaluation results of GEM, 
based on the values presented in Tables 1 and 2 in Section 5. 
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Fig. C 3. Time and Memory Results for Experiments Set 2 



